HTTP-ответ всегда возвращает код ответа 200, даже если запрос не выполнен, а код состояния возврата является частью REST

Question

Я недавно присоединился к новому проекту. В этом проекте все API-интерфейсы в службе всегда возвращают код состояния 200. Даже если этот ответ должен быть равен 400 или 404, API возвращает код состояния 200.

Я спросил причину, почему API не возвращают другие коды ответов, а программисты сказали мне, что они не используют код ответа. они помещают информацию в тело.

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

{"result" : "fail"}

если неавторизованный пользователь пытается получить доступ, код состояния равен 200, тело возвращается так

{"result" : "unautherized"}

То, что я делал раньше, было совсем другим, я всегда указывал код состояния в каждом конкретном случае и пытался вернуть подходящий код состояния и сообщение. Я думал, что это часть протокола HTTP. Тем не менее, они сказали мне, что указание кода состояния, такого как 400, 404, 300, является частью RESTful API, и возвращение всегда 200 - это правильный код состояния, потому что сервер ответил, и он жив. API всегда должны возвращать 200, кроме 500. Потому что, когда сервер умирает, он ничего не может вернуть.

Так вот в чем вопрос.

1. Сервер всегда должен возвращать код состояния 200, кроме случаев, когда сервер умирает?
2. Указание различных кодов состояния является частью REST API?
3. Часто не используется код состояния?

Answer 1

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

Я говорю это, потому что это звучит какКоманда не думала о том, как их текущая схема обмена сообщениями работает с родовыми участниками обмена сообщениями.

Например, кэширование является важной проблемой в архитектурном стиле REST.В HTTP RFC 7234 описывает семантику кэширования.В частности, есть раздел о том, как аннулирование кэша вызывается кодами состояния.Это, в свою очередь, говорит о том, что, если вы не проведете различий между кодами состояния в успешном и неуспешном случаях, то универсальные компоненты будут делать недействительными кэшированные записи, которые не должны быть аннулированы.

Answer 2

Я присоединился к проекту, который использует точно такую ​​же стратегию - встроить сообщение о статусе в тело ответа и оставить код состояния всегда 200. По соображениям согласованности лучше следовать существующей стратегии во время обслуживания программного обеспечения. Однако это не рекомендуется для любого нового проекта по причинам, указанным ниже:

1. "Указание кода состояния, например 400, 404, 300" , соответствует дизайну RESTful, но НЕ является частью REST. На самом деле, использование 302 (перенаправление), 401 (обычная и дайджест-аутентификация), 404 (страница по умолчанию не найдена на веб-сервере), 500 (страница ошибки сервера по умолчанию) популярно десятилетия назад, давно до RESTful API в наши дни (я знаю, что RESTful предлагается десятилетия назад, но он популярен только в последние годы).

2. «Возвращать всегда 200 - это правильный код состояния, потому что сервер ответил, и он жив» . Это неверно Если это так, то для кода состояния можно использовать только 200 - пока сервер «жив», он может возвращать сообщение. 500 также неприемлемо, так как в этом случае сервер все еще "жив", он не умирает ... Тогда, поскольку код состояния всегда должен быть 200, зачем нам код?

3. «Не используется код статуса, это часто встречается?» . На самом деле, все наоборот. Поскольку схема разработки RESTful API становится все более популярной, все больше проектов используют код состояния HTTP для доставки семантики сообщений. Но в любом случае, это точка зрения, основанная на мнении.

Answer 3

Сервер всегда должен возвращать код состояния 200, кроме случаев, когда сервер умирает?

Несколько лет назад я спросил то же самое о программной инженерии: Используют ли веб-приложения HTTP в качестве транспортного уровня или они считаются неотъемлемой частью HTTP-сервера? . См. Также Следует ли использовать коды состояния HTTP для описания событий уровня приложения .

Указание различных кодов состояния является частью REST API?

Нет, REST не зависит от транспорта. Это может использоваться поверх HTTP, но не нужно. Поэтому ничего не говорится о кодах состояния.

Часто не используется код состояния?

Зависит от того, кого вы спрашиваете.

Это вопрос предпочтений. Мне крайне не нравится «Какой код статуса наиболее подходит для сценария X?» вопросов. Также есть:

• Коды состояния HTTP
• Коды состояния ответа HTTP - руководство по REST API

И множество других. Я помню, что был сайт, предлагающий блок-схему для определения (наиболее) соответствующего кода состояния.

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