Почему для ответа на бизнес-логику в сервисе RESTful следует использовать код ответа HTTP?

Question

Я прочитал это: Каков соответствующий ответ кода состояния HTTP для общего неудачного запроса (не ошибка)?

Я понимаю принципы, но использование кода ответа HTTP для указания статуса службы RESTful API бизнес-логики кажется мне неоднозначным, повторяющимся и сбивающим с толку.

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

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

Для 404 клиент не знает, существует ли ресурс на сервере или бизнес-объект не существует. Он также должен заглянуть в тело ответа.

Так почему же люди продолжают использовать код ответа HTTP с ошибкой бизнес-логики? Для меня проще просто заглянуть в тело ответа на ошибку бизнес-логики и обработать ее. Есть ли какая-либо ситуация, когда необходимо использовать HTTP-ответ с ошибкой бизнес-логики?

Большое спасибо.

Answer 1

Так почему же люди продолжают использовать код ответа HTTP с ошибкой бизнес-логики?

При создании приложений, которые следуют архитектурному стилю REST по протоколу HTTP, вы адаптируете домен своего приложения к ресурсам , который является центральным элементом архитектуры REST.

Сервер предоставляет набор URL-адресов для определения местоположения ресурсов, и их состоянием можно управлять с помощью HTTP-глаголов и представлений, таких как JSON и / или XML. И HTTP-коды состояния используются для информирования клиента о состоянии операции. Вводящий в заблуждение код состояния будет содержать неверную информацию о состоянии запроса.

RFC 7231 определяет классы кодов состояния :

• 1xx (информационный): запрос получен, продолжение процесса
• 2xx (Успешно): запрос был успешно получен, понят и принят
• 3xx (Перенаправление): для выполнения запроса необходимо предпринять дальнейшие действия
• 4xx (ошибка клиента): запрос содержит неверный синтаксис или не может быть выполнен
• 5xx (ошибка сервера): серверу не удалось выполнить явно действительный запрос

Например, если запрос не выполнен из-за клиентской ошибки (например, неверно сформированный запрос или неверные данные были предоставлены в полезной нагрузке), возвращается код состояния 2xx или 5xx вводит в заблуждение здесь. Код состояния 4xx подходит для выражения причины ошибки.

Есть ли ситуации, когда необходимо использовать HTTP-ответ с ошибкой бизнес-логики?

Некоторые состояния, такие как 409 и 422, могут использоваться для представления ошибок бизнес-логики.

Мне проще взглянуть в тело ответа на ошибку бизнес-логики и обработать ее.

Это правда, что HTTP-кодов состояния иногда недостаточно, чтобы передать достаточно информации об ошибке, чтобы быть полезным. Но RFC 7807 был создан, чтобы восполнить этот пробел: он определяет простые документы JSON и XML для указания проблем.