Комментарии 14
Удивлен, что не упомянули Problem Details
...и более "свежий" Problem Details https://www.rfc-editor.org/rfc/rfc9457.html
Холивара ради: должен ли API всегда при ошибке возвращать http status != 200/302 или как в примере возвращать всегда 200, а в теле сообщать о проблемах?
Ну а зачем тогда вообще нужны HTTP коды?
Есть мнение, что можно оставить HTTP коды для транспортных ошибок.
А если достучались до бизнес-логики, то уже код 200 и не важно логика отработала или вернула ошибку.
Имеет право жить такое мнение, имхо.
Так и делаю.
Ошибка может возвращать информацию, касающуюся обработки данных, целостности переданных данных и другого рода ошибочные ситуации, которые в код 4xx и 5xx завернуть нельзя.
Каждый тут обычно сам решает, я использую стандратные коды. 400 - ошибка формата (например невалидный json или xml), 422 (Unprocessable Entity) - ошибка валидации, там где это подходит по логике - 409 (Conflict, например Id уже существует или что-то в этом духе). Все дополнительное, какие-то спец коды ошибок, traceId - внутри Problem Details ответа.
еще из минусов такого решения - в случае бизнес ошибок с 200 статусом вы их не увидите как ошибки в телеметрии a-la Application Insights и т.п., по крайней мере без танцев с бубном
Ну например многие фронтендеры «затрудняются» обработкой всех этих статусов. Имхо толтко сетевые ошибки должны иметь такие статусы и обрабатываться фреймворками как исключения. А бизнес ошибки должны приходить как 200 с кодами внутри.
Нет, не должны. Это порочная практика, раздуваемая в сообществе. Вместо стандартного подхода к обработке ошибок приходится делать несколько кругов ада обработки. И самое интересное, что ценности у такого решения 0. Что мешает в той же 400 вернуть дополнительный код. 400 это как раз код ошибки про ту самую бизнес логику. И далее, для чего все это? Дать пользователю какой-то внятный ответ? Зачем? Чтобы что? Чтобы он, получив сообщение, пошел в службу поддержки? Для этого нет необходимости ок200 использовать. Второй момент - возврат внутренних кодов ошибок по бизнес логике это частичное раскрытие внутренней реализации, что не очень хорошо. Есть куча сервисов, тот же sentry например, которые помогут вам на проде собрать ошибки. Не пишите костыли.
Кому как удобно
Кто-то API делает с учетом кодов и типов запроса
Кто-то работает только с 200-ым кодом но с разными типами запросов
А кто-то вообще только на POST запросах проектирует API
Считаю, что возвращать при ошибке код 2хх не правильно.
При 200 мы ожидаем ответ заданного формата который например сразу десириализутеся в структуру без предварительного парсинга тела ответа. (Что бы узнать, а что же там пришло).
Если при 200 могут приходить разные структуры, то значит нужно сначала как то определить какая структура пришла, а это лишнее время.
Как будто бы не совсем точный заголовок статьи. Ожидание, что там будет описано как фронтенд обрабатывает ошибки от REST API
{ "errors": [...] }
В современных форматах поле с ошибкой часто представлено в виде списка, а не одиночного объекта.
За этим стоит интересная теория https://stackoverflow.com/questions/12211776/why-isnt-validation-a-monad, которая в итоге подталкивает перекраивать всю обработку ошибок, если она была сделана иначе.
Обработка ошибок REST API: лучшие практики