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

Question

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

В случае успешного заказа я возвращаю 200 OK, а в случае, если запрос заказа неверен или недействителен, я возвращаю 400 Bad Request. Но что я должен вернуть, если возникла проблема при фактической обработке заказа?

1. Клиент размещает заказ на сервере для пользовательского ресурса. Если пользователь не существует, возвращается 404 Not Found.
2. Формат заказа и информация подтверждена. Если недействительный, возвращается 400 Неверный запрос.
3. Заказ обработан. Если заказ выполнен успешно, для заказа возвращается 201 Created. Если обнаружена непредвиденная ошибка, возвращается 500 Ошибка сервера.

Последний шаг - проблема - что мне вернуть, если заказ не выполнен по какой-либо другой причине? Возможные сценарии могут включать:

• Товар продан
• Достигнут максимальный предел заказа пользователя
• Ошибка транзакции по кредитной карте (недостаточно средств и т. Д.)

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

Редактировать: Также найдено это существующее обсуждение той же темы. Кажется, что все ответы там указывают на использование кодов состояния для этого типа нарушения, с некоторым обсуждением между использованием 400, 409 или расширения 422.

Answer 1

Вы должны использовать 400 для бизнес-правил. Не возвращайте 2xx, если заказ не был принят. HTTP - это протокол приложения, никогда не забывайте об этом. Если вы вернете 2xx, клиент может предположить, что заказ был принят, независимо от того, какую информацию вы отправите в теле. <Ч /> Из RESTful Web Services Cookbook :

Одна распространенная ошибка, которую допускают некоторые веб-сервисы, - возвращать статус код, который отражает успех (коды состояния от 200 до 206 и от 300 до 307), но включают тело сообщения, описывающее состояние ошибки. Это предотвращает обнаружение ошибок программным обеспечением с поддержкой HTTP. За Например, кеш будет хранить его как успешный ответ и служить Последующие клиенты, даже если клиенты могут быть в состоянии сделать успешный запрос.

Я оставлю вам выбор между 4xx и 5xx, но вы должны использовать код состояния ошибки.

Answer 2

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

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

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

Ошибка транзакции по кредитной карте будет ошибкой клиента. Клиент может повторно отправить запрос с другим методом оплаты или номером кредитной карты, чтобы обойти ошибку.

Answer 3

Тип ошибки:

4×× Client Error

Код ошибки:

422 Unprocessable Entity

Сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 Неподдерживаемый тип носителя является неподходящим), и синтаксис объекта запроса является правильным (таким образом, код состояния 400 Bad Request является неподходящим), но не смог обработайте содержащиеся в нем инструкции.

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

https://httpstatuses.com/422

Answer 4

Я знаю, что этот вопрос старый, но сегодня я задавал тот же вопрос.Если у моего пользователя закончились кредиты, какой код статуса должен вернуть мой REST API?

Я склонен склоняться к 402 Payment Required:

Согласно Википедия :

Зарезервировано для будущего использования.Первоначально предполагалось, что этот код может использоваться как часть какой-либо формы цифровой наличности или схемы микроплатежей, но этого не произошло, и этот код обычно не используется.Google Developers API использует этот статус, если конкретный разработчик превысил дневной лимит запросов.

И действительно они делают :

PAYMENT_REQUIRED (402)

• Достигнут лимит дневного бюджета, установленный разработчиком.
• Запрошенная операция требует больше ресурсов, чем позволяет квота.Для завершения операции требуется оплата.
• Запрошенная операция требует какой-либо оплаты от аутентифицированного пользователя.

Answer 5

Как насчет 424 Failed Dependency?Спецификация описывает его как:

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

Но есть также это определение :

Код состояния 424 определен в стандарте WebDAV и предназначен для случая, когда клиент должен изменить то, что он делает, - сервер не испытывает никакихпроблема здесь.

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

Насколько я понимаю, «действие» - это достаточно широкий термин, и его можно использовать в различных ситуациях, включая недостаточный запас, недостаточный кредит илиВечеринка на складе.

---

Другой вариант может быть 422 Unprocessable Entity:

Сервер понимает тип содержимого tон запрашивает объект (следовательно, код состояния 415 Unsupported Media Type не подходит), и синтаксис объекта запроса является правильным (таким образом, код состояния 400 Bad Request является неподходящим), но не смог обработать содержащиеся в нем инструкции.

Например, это условие ошибки может возникать, если тело XML-запроса содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные XML-инструкции.

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

---

Возможно, недостаточное количество акций или ночь на складе может считаться временным состоянием, поэтому запрос может быть повторен позже.Эта ситуация может быть обозначена как 503 Service Unavailable

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

Сервер МОЖЕТ отправить поле заголовка Retry-After, чтобы предложить клиенту соответствующее время для ожидания перед повторной попыткой запроса.

Answer 6

Не думаю, что 400 можно использовать для всех бизнес-сценариев. Может использоваться для проверки правильности ввода основных данных. Кроме того, нам может быть трудно вовремя вставить другую бизнес-логику в этот код ошибки. Обрабатываемые этим ошибки - это, в основном, ошибки времени разработки, с которыми разработчик может столкнуться, возможно, во время кодирования клиента.

Допустим, все параметры верны, и допустим, что мы передаем номер учетной записи пользователя в запрос.

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

Я бы предложил использовать 403 с соответствующим сообщением об ошибке в этих сценариях.

Другой возможный код ошибки: конфликт 409. Но это используется в тех случаях, когда ресурс находится в согласованном состоянии.

Answer 7

Я иду с 406 Not Acceptable.

Вот список 4хх:

const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418;                                               // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421;                                         // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422;                                        // RFC4918
const HTTP_LOCKED = 423;                                                      // RFC4918
const HTTP_FAILED_DEPENDENCY = 424;                                           // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425;   // RFC2817
const HTTP_UPGRADE_REQUIRED = 426;                                            // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428;                                       // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429;                                           // RFC6585