Согласен, код ответа важен. Или если код ответа один, также хорошо иметь параметр в ответе, который может детализировать тип ошибки, если с одним кодом могут быть разные кейсы. Ну например 404, но могут быть не найдены разные сущности из запроса (может хреновый пример щас привел).
Читать полностью…Вот пусть каждый и делает трансляцию ошибок
Имхо это зашквар пользователю показывать текст ошибки, которая пришла с бэка
Особенно эта сотня партнёров будет рада коду ошибки, который они смогут разобрать и что то сделать, а не опираться на какой то текст
1. Выбор языка на фронте это норма, если пользователь авторизован, то это просто перегружает настройку профиля. Если пользователь не авторизован и нет выбранного языка - это делается из браузера
2. Зачем бэку передавать язык, если он передаёт данные не привязанные к языку? Например не передаёт текст ошибки?
3. Это норма на каждом фронте делать ошибки, тем может даже отличаться в зависимости от того это веб или мобилка
Проблема в том, что бывают случаи, когда у тебя сначала один фронт. А потом приходит заказчик и говорит, а давайте прихерачим сюда еще 3 сайта, приложухи и заодно этот апи дадим 100 партнерам… и тут занавес, или все переделывать, или как-то жить и выживать. Я лучше сразу такие риски заложу, чем потом локти кусать, тем более, что на начальном этапе это проще простого.
Читать полностью…Все так. Только еще есть неавторизованный пользователь, ну и вообще кейсы когда исходя из UI/UX надо делать выбор языка например в шапке сайта, а не в профиле. И кейс, когда по каким-то причинам в сервис не передали Accept-Language, и тогда надо определить дефолтную локаль, и желательно рассказать фронту, на каком языке ты ответил. И у меня дороже на фронтах делать перевод ошибок из кодов в текст, проще и я считаю лучше в одном месте на беке сделать.
Читать полностью…И заголовок поправил наконец. ResponseBodyAdvice помог, я раньше на него натыкался в доке, но не допер, что им можно не только тело поменять.
Читать полностью…Главное не забыть http status code поставить, а то 200 с json, в котором errorMsg -- особенно клёво выглядит
Читать полностью…2. В целом не за чем, но проще сделать что он всегда говорит в ответе, на каком языке он отвечает. Чтобы не придумывать как исключать запросы, где не надо это делать. Хотя в принципе можно, думаю.
3. То что ошибки надо иметь возможность обрабатывать как-то специфически на фронте - это факт. Бывают кейсы когда это необходимо. Но 90% сообщений можно кидать в Toast-message. Если конечно твой бек по уму сделан.
Вообще обычно делают локаль пользователя, которая хранится у него в акк, её загружает с акк пользователя фронт и в этом языке отрисовывает
А ошибки - принято кидать кодами, а у фронта в каждой локали на каждый код свой текст
Нет, не только при exception, но и там тоже, и не хочу, а уже сделал. Только надо еще заголовок поправить.
Читать полностью…Я с php-симфони переезжаю. Ее сдирали со спринга судя по всему. Многое очень похоже. Я просто кайфую сейчас, многие вещи даже гуглить не надо, интуитивно делаю и работает. Только костылей меньше)
Читать полностью…