Наброшу и сюда тоже, пожалуй.
Сегодня снова была беседа на тему смешивания транспортного уровня и логического.
В смысле я тут периодически вижу горение, когда сервис возвращает 200, а внутри {"error": "go fuck yourself"}. И с моей точки зрения это вообще выглядит абсолютно нормально, потому что HTTP слой работает, сервер в норме, запрос дошёл, ответ вернулся. А вот то, что в запросе была написана херня, это вообще ни разу не проблема сервиса.
Но в комментах к каждому такому треду обязательно найдётся эксперт, который скажет, что нельзя возвращать двухсотый код при ошибке.
А я вот реально не понимаю этой проблемы. Скажем, у нас внутренние сервисы (типа гитхаба) по той же логике работают.
Если сервис начал пятисотить — надо срочно жаловаться овнеру сервиса.
Ну для четырёхсотых — возможны варианты. Скажем, я регулярно наступаю на 429, но тут я сам виноват, да.
А вот @skobkin говорит, что принято возвращать ОШИБКУ, если что-то пошло не так.
Но я вот сейчас пилю сервис на axum, и там когда что-то реально ИДЁТ НЕ ТАК, типа сервер возвращает 404, то падение происходит на уровне middleware, и ты это обрабатываешь реально как exception. Ну то есть проблема уровня «Хозяин, там сломалась труба, по которой ходили запросы!». А если ты просто запросил что-то не то, и тебе вернулась ошибка, то ты получаешь самый обыкновенный Result, и обрабатываешь его, как Result: там может быть ответ, а может быть ошибка, но это именно логическая ошибка, не ошибка транспортного слоя.
Для меня реально немного диковато выглядит вот этот прикол с тем, что сервер тебе возвращает 401, если ты запросил то, что тебе запрещает бизнес-логика, а не попробовал отправить запрос в эндпоинт чужого сервиса.
@skobkin @rayslava в новой - договаривайтесь. Сам я за стандарты, просто потому что новый член команды сразу будет понимать, что происходит. Но верю, что возможны ситуации, когда можно отвечать 200 на всё. От "надо СЕЙЧАС" до "чтобы задолбать скрипт кидди".
Если делаешь для внешнего пользования, то только стандарт, разумеется.
@umnik
@rayslava пишет не про команду, а про то, как надо делать "вообще". Ну, то есть в индустрии.
То, что в какой-то конкретной команде ты можешь договориться хоть о том, что на успешный запрос будешь возвращать 400 и все будут следовать - это и так понятно.
> Если делаешь для внешнего пользования, то только стандарт, разумеется
Так вот а что стандарт? Вопрос-то в этом.
Ты можешь воспринимать HTTP как трубу, а можешь - как протокол своего приложения. И тогда подходы к кодам ошибок могут быть разные.
Если это труба - тогда 200 можно ответить если ты достучался до бизнес-логики и она что-то вернула - неважно, что.
Если это протокол твоего приложения, то тогда если бизнес-логика возвращает ошибку, то её надо отражать в коде ответа.
@skobkin это ты причину описываешь. Мы все её понимаем. Но для заведения дефекта были условия, что на плохой запрос должен быть ответ "плохой запрос". То есть с точки зрения "результат проверки" это именно 500 вместо 400. А под капотом да, типичная проблема, когда просто передали без проверки, а БД ругнулась на вставке, например. Просто для заведения баги это не важно [в той структуре организации было] @3draven @rayslava
@3draven нет, не нравится. Но прям такого у меня никогда и не было. А вот отдавать 500 вместо 400 - это прям было @skobkin @rayslava