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

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

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

  1. клиент отправляет заказ на сервер для пользовательского ресурса. Если пользователь не существует, 404 не найден возвращается.
  2. формат заказа и информация проверяется. Если он недействителен, возвращается 400 неверных запросов.
  3. заказ обрабатывается. Если заказ выполнен успешно, 201 созданный возвращается для заказа. При обнаружении непредвиденной ошибки возвращается ошибка сервера 500.

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

  • товар распродан
  • максимальное ограничение, если пользователь еще не достиг
  • сбой транзакции по кредитной карте (недостаточные средства и т. д.)

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

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

6 75
http database-restore http-status-codes

6 ответов:

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

От RESTful Web Services Cookbook:

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

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

71

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

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

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

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

15

ошибка типа:

4×× Client Error

код ошибки:

422 Unprocessable Entity

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

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

https://httpstatuses.com/422

15

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

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

по данным Википедия:

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

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

PAYMENT_REQUIRED (402)

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

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

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

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

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

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

2

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