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

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

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

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

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

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

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

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

Вы должны использовать 400 для бизнес-правил. Не возвращайте 2xx, если заказ не был принят. HTTP - это протокол приложения, никогда не забывайте об этом. Если вы вернете 2xx, клиент может предположить, что заказ был принят, независимо от любой информации, которую вы отправляете в теле.

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

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

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

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

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

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

Тип ошибки:

4×× Client Error

Код ошибки:

422 Unprocessable Entity

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

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

https://httpstatuses.com/422

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

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

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

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

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

ТРЕБУЕТСЯ ОПЛАТА (402)

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

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

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

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

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

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

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

Другой вариант 422 Unprocessable Entity:

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

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

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

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

Loopback 4 использует 422, когда проверка ввода не выполняется.

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

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

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

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

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

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

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

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

Я использую 406 Not Acceptable.

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

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