Является ли 200 OK с телом ошибки антипаттерном REST?

Question

[j_KS]

Встречается API, который всегда возвращает 200 OK, а бизнес-ошибку передает в JSON:

{ "status": "error", "message": "..." }

Насколько это допустимая практика? Какие могут быть проблемы?

Comments

[Adamos]

В такой практике нет ничего страшного, пока механизм примитивен: скрипт отправляет запрос и разгребает ответ.
Но эту схему можно немножко усложнить и ввести посредника, который тянется к API, но не ковыряется в ответе.
В случае корректных ошибок со стандартными кодами он сможет сам обрабатывать тривиальные проблемы (переотправляя запрос при недоступности сервиса, например), возвращая на разбор только корректные ответы.

[firstmixon]

Вопрос к автору, как он себе представляет обработку данных?
Клиент отправляет данные, Сервер сообщает о "Неточностях" или сразу сыпаться?

[Сергей Водаков]

Adamos,

переотправляя запрос при недоступности сервиса

Ну, при недоступности сервера, сервер в любом случае не сможет вернуть 200
Как правило это используется для ошибок в бизнес слое. И помоему 200 тут вполне уместно, 200 говорит о том, что техническая часть работает.

[Adamos]

Сергей Водаков, я говорил про недоступность сервиса, а не сервера.
Сервис, например, может быть недоступен по причине 200 OK {"error":"Нас тут ддосят, зайдите попозже"}

[Сергей Водаков]

Adamos, Ну, при таком сценарии, 200 точно не к месту.

[Adamos]

Сергей Водаков, если при любом запросе проверяется заполненность error в ответе - может быть и такое.

Answer 1

[Mors Clamor]

Да, если вы работаете с HTTP то необходимо использовать и коды ответов самого протокола. Можете, конечно, этого не делать, если, например, делаете для себя проект. Да и причин этого НЕ делать нет

Comments

[Василий Банников]

Не обязательно.
gRPC и JSON-RPC например сделаны поверх http и всегда 200 код возвращают, а подробности - в своих заголовках и теле.

Но там это сделано осознанно, чтобы не дублировать обработку ошибок.

[Mors Clamor]

Василий Банников, именно, http, если в него что-то инкапсулировано, просто транспорт, а за всё остальное отвечает инкапсулированный протокол

Answer 2

[Василий Банников]

Проблема в том что теперь потребителю этого API нужно будет читать вашу документацию, чтобы корректно обрабатывать ошибки (всегда быть готовым к ошибке с 200 кодом и парсить ответ), а вам это нужно достаточно подробно и однозначно описать.

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

По хорошему следует возвращать 2xx только если все реально успешно, 4xx - если есть какая-то ошибка, которая возникла по вине клиента, и 5xx - если ошибка по вине сервера.

Если нужно что-то дополнительно бизнесовое сообщить - можно и нужно передать это в теле ответа.

По формату ответа с ошибкой рекомендую посмотреть на RFC 9457 Problem Details for HTTP APIs

Comments

[Владимир]

Проблема в том что теперь потребителю этого API нужно будет читать вашу документацию

Проблема в том, что документацию надо читать всегда ;)

[Василий Банников]

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

Опять же и вам, как автору - придётся больше писать и уделять больше внимания тому, чтобы документация была полная, актуальная, и непротиворечивая.

Если ваш API является продуктом, за который потребитель платит - такие препятствия могут сделать ваш продукт менее привлекательным по сравнению с альтернативами.

[Владимир]

Василий Банников, нет, вы ошибаетесь. Кроме документации, но она и должна быть полная, актуальная, и непротиворечивая. В отличие от тех быдлодоков, которые генерят быдлокодеры с помощью быдлодокогенераторов)

[Василий Банников]

Владимир, кажется спор сводится к skill issue :)

Тоесть вы не согласны, что если использовать стандартные подходы, то:
1. Разработчик сможет меньшими усилиями поддерживать документацию
2. Клиент сможет с меньшими усилиями интегрироваться
3. Поддержке реже придётся отвечать на глупые вопросы из-за того что кто-то не дочитал про нюансы
4. Высвободившиеся ресурсы можно будет потратить на что-то более полезное (или хотябы приятное)

Или в чём именно я не прав?

В том что если отдавать 200 OK только при успехе, а 4хх/5хх только при ошибках, то в метриках будет корректно посчитан процент ошибочных запросов?

[Владимир]

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

[Василий Банников]

Владимир,

нет, вы ошибаетесь

Тогда покажите, в чём я ошибаюсь, а то приходится играть в угадайку, в чём именно ошибка у меня.

Answer 3

[rPman]

есть разные классы ошибок, а точнее они классифицируются по тому, какое поведение должно быть у пользователя (клиента).

В общем можно разделить ошибки на следующие типы:
* можно продолжать но пользователь должен быть уведомлен - warning
* требуют повтор последнего действия - простые
* требуют откат и повтор группы действий - сложные, нужна своя логика отработки
* требуют остановку и вмешательство пользователя - фатальные

Так вот ошибки второго типа могут быть без проблем не 200-го кода возврата, тогда библиотека на уровне отправки запроса может его повторить.

Все остальные требуют обработку более высокого уровня, и без проблем такие сообщения могут и должны быть 200 код возврата

p.s. отсюда, к примеру проблема прав доступа, это фатальная проблема, если делать код возврата не 200, то библиотека должна правильно это интерпретировать и не делать бессмысленные повторы.

Answer 4

[Василий]

>Является ли 200 OK с телом ошибки антипаттерном REST?
ДА.

Все кто будут пользоваться таким Апи проклянут разработчика. Других последствий не будет.
К сожалению у нас нет REST полиции.

Answer 5

[Владимир]

Выше уже дали правильный и исчерпывающий в общем-то ответ, но, как разработчик в т.ч. API, подчеркну, что ошибки бывают разные. Когда используется код 200, но в ответе идет { "status": "error", "message": "..." }, то речь идет об ошибке уровня пользователя системы. Это пользователь захотел странного и был вежливо послан, с указанием в чем он неправ, а все остальное отработало как положено. Именно для разделения источников и уровней ошибок и используется такой подход. И, да, всегда надо читать документацию, это очень и очень полезно)