Валидируй в браузере. У них больше мощностей, чем на твоём сервере. Остальное отдавай с 404. Мамины хаккиры и все такое

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

иначе тебе coupling заблокирует все

Мои пользователи - другие приложения и люди с терминалом например

Особенно если у тебя внешний API. Возвращаем сразу error 500 и нанимаем пачку людей на поддержку, которые будут логи по жалобам клиентов присылать. Ага.

тем более - туда имеет смысл ответить “зайди потом”, и “не звони сюда больше”

Обрабатывай на клиенте

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

куда они идут - рашай сам, но “внутренние типы не должны…”

Я только недавно ругался с прогерами и объяснял им, что любая ошибка 500 без чёткого объяснения причин и иже с ними - дефект на их ПО. ПО на гарантийной поддержке, SLA довольно жёсткий, поэтому их поддержке будут звонить даже ночью и ипать мозг. А если не смогут - будут звонить по цепочке вплоть до владельца компании и напоминать про нарушение SLA.

К сожалению, помогает только так. И то не всегда ;(

и чего - 500 с четким объяснением помогает?

если да - надо писать четкое объяснение, конечно

500 это internal server error, значит серверу поплохело.

Если на вход вместо json получил кашу - будь добр вернуть ответ в соответствии со спекой. Если в спеке только json, то и пиши в json error с как минимум комментом об invalid request body.

а, это да

но - это как раз то, о чем я говорю. к клиенту уехал ответ, а не ошибка

С 200?

с 200, да

ну или с 500, если вы так договорились

Если мы на все свои ошибки отдаём 200 с ошибкой которую фронт обрабатывается, зачем вообще тогда 500

есть протокол http - в нем 500 кое-что означает

есть RESTful протоколы - в них тоже 500 кое-что означает

а есть разнообразные другие протоколы, в которых 500 означает то, что в этом протоколе прописано

Скорее всего говорим об одном и том же, но разными словами ;))

В любом случае клиент обязан получить ответ в том формате, который специфицирован в обмене.

В некоторых случаях клиенту можно прямо текст транслировать (соблюдая спеку). Хотя смотря какой текст - если ошибка от валидатора input данных, то можно прямо текст отдать.
А если это ошибка БД, то клиенту можно вернуть общий текст "db error", текст может содержать что-то важное.

В идеале - выдать что-то вроде "server error #ID ошибки/потока/запроса".

ID ошибки/потока/запроса это уже высший пилотаж, тогда админу можн сдать проблему не уровня "от вас ошибка прилетела", а "вот ID, посмотри причины и пофиксь".

прямо текст? а i18n как же?