pro.jvm

22 Dec 2024 11:19

А переводить должен тот кто занимается отображением

pro.jvm

22 Dec 2024 11:18

Потому что текстовый код нагляднее - понимаешь сходу и не надо в доку лезть.

pro.jvm

22 Dec 2024 11:17

Почему? Если у тебя есть база знаний по кодам ошибок, их описанию и способам решения, то это очень помогает поддержке. Плюс кейс выше по маппингу кода на перевод. Но код может быть и не числовым

pro.jvm

22 Dec 2024 11:17

status: the HTTP status code applicable to this problem, expressed as a string value.

gspdee

pro.jvm

22 Dec 2024 11:03

Зачем переводить бек? Берешь https://jsonapi.org/format/#error-objects . Код ошибки уникально идентифицирует паттерн перевода (например xliff). В meta суешь мапу с плейсхолдерами. На клиенте определяешь язык и все для перевода уже выше описано.

pro.jvm

22 Dec 2024 10:46

Для начала я бы вообще отделил ошибки от некорректного запроса

pro.jvm

22 Dec 2024 10:36

Ну в принципе да, там ведь у каждого метода итак ошибки описаны быть должны.

pro.jvm

22 Dec 2024 10:36

Ну кстати как вариант - использовать имя класса исключения.

pro.jvm

22 Dec 2024 10:33

Кстати хорошая мысль сейчас родилась. Можно в API публиковать отдельным методом все коды ошибок и что они значат.

pro.jvm

22 Dec 2024 10:30

А может и просто объясняющий текст

pro.jvm

22 Dec 2024 10:29

Он может быть и текстовый enum

pro.jvm

22 Dec 2024 10:29

Числовой код ошибки - абсолютно бесполезная вещь

pro.jvm

22 Dec 2024 10:28

Код ошибки это не http status, это поле error code из тела ответа

pro.jvm

22 Dec 2024 10:26

Согласен, код ответа важен. Или если код ответа один, также хорошо иметь параметр в ответе, который может детализировать тип ошибки, если с одним кодом могут быть разные кейсы. Ну например 404, но могут быть не найдены разные сущности из запроса (может хреновый пример щас привел).

pro.jvm

22 Dec 2024 10:25

Вот пусть каждый и делает трансляцию ошибок

Имхо это зашквар пользователю показывать текст ошибки, которая пришла с бэка

Особенно эта сотня партнёров будет рада коду ошибки, который они смогут разобрать и что то сделать, а не опираться на какой то текст

pro.jvm

22 Dec 2024 11:19

Я не отрицал что в ошибке надо вернуть человекочитаемое описание. Я считаю что с бека оно должно лететь на en-us

pro.jvm

22 Dec 2024 11:17

Зачем она нужна, когда ты прямо там можешь написать, в чём проблема?

pro.jvm

22 Dec 2024 11:17

Профит для кого? Для бекендера, который слентяйничал? А ничего что потом трудозатрат больше переводить это на всех фронтах?

pro.jvm

22 Dec 2024 11:13

Бек ниче не знает про переводы. Профит. Ошибку рендерит фронт. Профит. Xliff пишут переводчики. Профит. А то начинается, в логах бека ошибки на русском, испанском, китайском...

pro.jvm

22 Dec 2024 10:47

В случае с первым код не нужен, потому что ошибку обрабатывать не имеет смысла
Во втором случае код не нужен, потому что пользователю надо вывести описание

pro.jvm

22 Dec 2024 10:42

Вот чего точно не стоит делать, так это кишки имплементации отдавать. И Боже упаси стектрейсами швыряться. И с сообщениями об ошибках с авторизацией-аутентификацией тоже осторожнее

pro.jvm

22 Dec 2024 10:36

Для этого есть openapi документация

pro.jvm

22 Dec 2024 10:35

Кмк, enum для ошибок - анти-паттерн.

pro.jvm

22 Dec 2024 10:30

Enum я считаю лучше всего

pro.jvm

22 Dec 2024 10:29

https://stackoverflow.com/a/45215327

pro.jvm

22 Dec 2024 10:29

Классика кровавого тырпрайза с заумными архитекторами

pro.jvm

22 Dec 2024 10:28

Ясно - ну в общем да, я это и уточнил

pro.jvm

22 Dec 2024 10:28

Главное не забыть http status code поставить, а то 200 с json, в котором errorMsg -- особенно клёво выглядит

pro.jvm

22 Dec 2024 10:26

2. В целом не за чем, но проще сделать что он всегда говорит в ответе, на каком языке он отвечает. Чтобы не придумывать как исключать запросы, где не надо это делать. Хотя в принципе можно, думаю.
3. То что ошибки надо иметь возможность обрабатывать как-то специфически на фронте - это факт. Бывают кейсы когда это необходимо. Но 90% сообщений можно кидать в Toast-message. Если конечно твой бек по уму сделан.

pro.jvm

22 Dec 2024 10:23

Так я вроде обратного не утвеждал