Какой вариант реализации Rest API лучше? Тот, который в случае ошибок шлёт коды 404 и т.п., или другой с 200 и ошибкой?

Question

Какой вариант реализации Rest API лучше? Тот, который в случае ошибок шлёт коды 404 и т.п., или другой с 200 и ошибкой?

Егор Демидович Мастер (1684), на голосовании 1 год назад

Есть два подхода обработки сценариев, когда что-то где-то по бизнес логике не нашлось.
Сервер может слать коды 404 в данном случае. Но также может слать 200 с указанием конкретной ошибки как объекта в самом теле ответа. Как вы думаете, какой вариант правильнее?

Answer 1

Ну ты же сам ответил на свой вопрос. Если СЕРВЕР будет отвечать 404, то значит такого файла/метода нет, а вот если отвечает АПИ, то от СЕРВЕРА в любом случае будет ответ 200, но в теле ответа от АПИ нужно указать код ошибки...

Answer 2

У http кодов есть вполне понятное назначение, которое всем понятно:

Код 200 - означает положительный ответ (ОК)
Код 400 - не корректный запрос от пользователя (нужно изменить запрос и попробовать еще раз)
Код 404 - означает что искомый ресурс не найден (допустим страница пользователя с id xxx)
Код 500 - ошибка на стороне сервера (пользователю ничего делать не нужно, программисты уже занимаются починкой)

Answer 3

Столяров Роман Гуру (2744) 1 год назад

Это религиозный вопрос )
Если клиенту достаточно кодов HTTP, то можно слать и 404 с 500.
Если есть причина думать, что на клиенте будут обрабатываться специфические коды ошибок, то лучше второй подход - с 200 и кодом ошибки в теле ответа.
А можно и совмещать - работать по кодам HTTP, но на будущее предусмотреть в ответе поле кастомного кода.

Егор ДемидовичМастер (1684) 1 год назад

Вот именно, что религиозный. Но есть ведь Rest API, это стандарт, вот по этому стандарту какой из вариантов подразумевается как основной?

Столяров Роман Гуру (2744) Егор Демидович, Строгого стандарта по использованию кодов возврата в REST нет. Есть рекомендации использовать коды возврата HTTP. И есть best practices, исходящие в основном из практики разработки API-систем. Считается (именно считается, но не стандартизовано), что правильно возвращать ошибки в коде HTTP. 1. для того, чтобы не тратить время на клиенте на парсинг тела ответа. 2. для того, чтобы не нагружать простые PUT или DELETE запросы телом ответа. Что не отменяет того факта, что клиенту может потребоваться расширенная информация об ошибке, включающая специфический код ответа, сообщение об ошибке, stack trace в dev-конфигурации или action, который сервер рекомендует выполнить клиенту.