400 против 422 для запроса об ошибке клиента

Я прочитал много сообщений и статей о правильном коде статуса http для возврата при ошибке запроса клиента. Другие предлагают использовать 400, как это было переопределено в RFC 7231, хотя я Я не уверен, что приведенный пример охватывает все ошибки клиента, которые я представлял себе, потому что примеры являются синтаксическими.

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

Я нашел это утверждение в Приложении B RFC 7231:

Код состояния 400 (неверный запрос) был смягчен, поэтому он не ограничивается синтаксическими ошибками. (Раздел 6.5.1)

Означает ли это, что я могу считать любую ошибку клиента плохим запросом? Было бы лучше использовать 400 для клиентских запросов и просто указать в сообщении более конкретную ошибку?


С другой стороны, другие говорят, что лучше использовать 422 (Unprocessable Entity). Хотя он больше ориентирован на семантику, он указан только в RFC 4918, который является расширением webDAV для http /1.1

Код состояния 422 (Unprocessable Entity) означает, что сервер
понимает тип содержимого объекта запроса (следовательно, код состояния
415 (Unsupported Media Type) не подходит), а синтаксис
объекта запроса правильный (таким образом, код состояния 400 (неверный запрос)
недопустим), но не смог обработать содержащиеся инструкции. Например, это состояние ошибки может возникнуть, если тело запроса XML
содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML.

Могу ли я использовать коды расширения webDAV для обработки моих HTTP-запросов? В случае 422, могу ли я использовать его, даже если его нет в основных кодах http.

Должен ли я использовать 400 или 422 для моей ошибки клиента?

Вот возможные ошибки клиента, которые я имею в виду:

1.) Invalid parameter. The client provided parameters but are found invalid. Example: I said that the userId is 1, but when I checked there's no userId of 1. Another example of invalid parameter is wrong data type.
2.) Missing required parameters
3.) Let's say I need to hash a value based on given params and it failed 
4.) Blocked content is being used. Like, i want to apply for membership and i passed the userId of 1. However, userId of one is blocked / deactivated
5.) When I try to delete an entry but the entry is still being used in another table. 
6.) Let's say i require a signature in my payload and the signature does not match when recalculated in the backend
7.) Let's say I have a value that counts a specific attribute like "shares" and it has reached the maximum value like 10.
etc...


Мы будем благодарны за любой информативный ответ. Спасибо большое, ребята!

Обновление: я проверил ошибки google api, и они не используют 422. С другой стороны, Twitter использует 422. Я запутался больше, чем когда-либо>. ‹Хотя есть часть меня, которая думает, что 400 - лучший выбор, поскольку он включен в документе RFC, а 422 - нет. Хотя я мог ошибаться.


error-handling http-status-code-400 http-error http-status-code-422 http-status-codes
person cessmestreet    schedule 23.08.2018    source источник
comment
Вы могли бы получить консультацию у ваших клиентских разработчиков, или вы создаете общедоступный API? Я бы выбрал 400 просто потому, что это имеет смысл для большего числа людей. Если вы бросите им 422, некоторым (большинству) нужно будет зайти в Google. Это ваш api и ваш звонок. наверное   -  person Jocke    schedule 24.08.2018
comment
спасибо @Jocke, ты прав. Я пошел с 400.   -  person cessmestreet    schedule 28.08.2018

Ответы (1)


arrow_upward
36
arrow_downward

Могу ли я использовать коды расширения WebDAV для обработки моих HTTP-запросов? В случае 422, могу ли я использовать его, даже если он не входит в базовые коды HTTP.

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

Что следует использовать для ошибки моего клиента: 400 или 422?

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

В качестве примера см. подход, используемый GitHub v3 API:

Ошибки клиента

Существует три возможных типа клиентских ошибок при вызовах API, которые получают тела запроса:

  1. Отправка недопустимого JSON приведет к 400 неверному ответу на запрос.

    HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

  2. Отправка значений JSON неправильного типа приведет к ответу 400 Bad Request.

    HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

  3. Отправка недопустимых полей приведет к ответу 422 Unprocessable Entity.

    HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Выбор наиболее подходящего 4xx кода состояния

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

Коды статуса HTTP 4xx

Детали проблемы для HTTP API

Коды состояния HTTP иногда недостаточны, чтобы передать достаточно информации об ошибке, чтобы быть полезной. RFC 7807 определяет простые форматы документов JSON и XML для информирования клиента о проблеме в HTTP API. . Это отличная отправная точка для сообщения об ошибках в вашем API.

Он также определяет типы носителей application/problem+json и application/problem+xml.

person cassiomolin    schedule 30.08.2018