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

Question

Я прочитал много постов и статей, касающихся правильного кода статуса 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(неподдерживаемый тип носителя) недопустим), а
синтаксис объекта запроса является правильным (таким образом, 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...

Любой информативный ответ будет высоко оценен. Большое спасибо, ребята!

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

Answer 1

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

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

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

Это зависит, но вы могли бы использовать оба. В общем, используйте 400 указывать синтаксические ошибки в полезной нагрузке или неверные параметры в URL. А также 422 указать на семантические проблемы в полезной нагрузке.

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

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

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

1. Отправка неверного JSON приведет к 400 Плохой ответ на запрос.

   HTTP/1.1 400 Bad Request
   Content-Length: 35
   
   {"message":"Problems parsing JSON"}
   

2. Отправка неправильного типа значений JSON приведет к 400 Плохой ответ на запрос.

   HTTP/1.1 400 Bad Request
   Content-Length: 40
   
   {"message":"Body should be a JSON object"}
   

3. Отправка неверных полей приведет к 422 Необработанный ответ сущности.

   HTTP/1.1 422 Unprocessable Entity
   Content-Length: 149
   
   {
     "message": "Validation Failed",
     "errors": [
       {
         "resource": "Issue",
         "field": "title",
         "code": "missing_field"
       }
     ]
   }
   

---

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

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

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

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

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