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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Тип ошибки:

4×× Client Error

Код ошибки:

422 Unprocessable Entity

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

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

https://httpstatuses.com/422

Ответ 4

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

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

Согласно Wikipedia:

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

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

PAYMENT_REQUIRED (402)

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

Ответ 5

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

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

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

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

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

Ответ 6

Я иду с 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