МВ
или я тебя не так понял?
Size: a a a
2021 May 18
RU
много факторов: публичное апи или нет, насколько сложная валидация, нужно ли поддерживать локали, знает ли бек о локалях клиента
D
по дефолту при валидации 422 будет такой выхлоп
{
"title": [ "can't be blank" ]
}
RU
не http коды - это отдельный холивар
RU
некоторые отдают только 200, 401, 500
D
я вижу тут такие варианты
- фронт всегда занимается i18n и бэк не знает ничего о локалях, возвращает коды
- фронт рендерит сообщения об ошибках напрямую, но тогда бэк должен знать о локалях, получается i18n ответственность делится между фронтом и бэком
я просто думал здесь есть какие то сформировавщиеся best practices
- фронт всегда занимается i18n и бэк не знает ничего о локалях, возвращает коды
- фронт рендерит сообщения об ошибках напрямую, но тогда бэк должен знать о локалях, получается i18n ответственность делится между фронтом и бэком
я просто думал здесь есть какие то сформировавщиеся best practices
RU
есть, но “it depends”, в целом ты все правильно описываешь
u
В варианте, когда фронт отвечает за сообщения - бывает очень непросто со старыми мобильнными клиентами
u
Решили вы, наприимер, ввести ограничения за мошенничество - а на старые клиенты уже не прокинешь ошибку
D
хороший пункт, добавлять валидации на лету без деплоя фронта
RU
ну да, старые клиенты будут видеть "неизвестная ошибка, обновите клиент"
u
Так тоже можно, да
u
Но не всегда хорошо)
RU
повторюсь, что очень многое зависит от того, публичное апи или нет
u
хз, в публичном апи тоже часто бывает и код и человеческое описание
u
имхо это неплохо
RU
если это паблик апи, то если клиент хочет арабский язык, то выкусывать сообщения из английского не кайф
RU
тоже неплохо да
u
Хотя самая дичь, которую я видел, была такой: сервис всегда возвращает http 200, в теле ответа - есть status (отдать юзеру) и realStatus - для разработчиков 😄
RU
ну 200 это один из вариантов нормальных