web-dev-qa-db-fra.com

400 vs 422 pour la demande d'erreur client

J'ai lu beaucoup de messages et d'articles concernant le bon code d'état http pour revenir en cas d'erreur de demande client. D'autres suggèrent d'utiliser 400 car il a été redéfini dans RFC 7231 bien que je ne sois pas sûr si l'exemple donné couvre toutes les erreurs du client dans mon esprit car les exemples sont syntaxiques.

Le code d'état 400 (mauvaise demande) indique que le serveur ne peut pas ou ne traitera pas la demande en raison de quelque chose qui est perçu comme une erreur client (par exemple, syntaxe de demande mal formée, demande non valide
cadrage des messages ou routage des demandes trompeuses).

J'ai trouvé cette déclaration dans l'annexe B du rfc 7231:

Le code de statut 400 (Bad Request) a été assoupli afin qu'il ne soit pas
limité aux erreurs de syntaxe. (Section 6.5.1)

Est-ce à dire que je peux considérer tout type d'erreur client comme une mauvaise requête? Serait-il préférable d'utiliser 400 pour les demandes des clients et de simplement spécifier une erreur plus spécifique dans le message?


D'autre part, d'autres disent qu'il vaut mieux utiliser 422 (Entité non traitable). Bien que cela soit plus axé sur la sémantique, il est uniquement répertorié dans RFC 4918 qui est une extension webDAV pour http/1.1

Le code d'état 422 (Entité non traitable) signifie que le serveur
comprend le type de contenu de l'entité de demande (d'où un
Le code d'état 415 (Type de support non pris en charge) est inapproprié) et le
La syntaxe de l'entité de requête est correcte (donc une 400 (Bad Request)
code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un XML
le corps de la demande contient bien formé (c'est-à-dire, syntaxiquement correct), mais
instructions XML sémantiquement erronées.

Puis-je utiliser ces codes d'extension webDAV pour gérer mes demandes http? Dans le cas du 422, puis-je l'utiliser même s'il n'est pas dans les codes http de base.

Dois-je utiliser 400 ou 422 pour mon erreur client?

Voici l'erreur client possible que j'ai en tête:

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...


Toute réponse informative sera très appréciée. Merci beaucoup, les gars!

Mise à jour: j'ai vérifié les erreurs de Google api et elles n'utilisent pas 422. D'un autre côté, Twitter utilise 422. Je suis plus confus que jamais>. <Bien qu'il y ait une partie de moi qui pense que 400 est le meilleur choix car il est inclus dans le document RFC et 422 ne l'est pas. Je pourrais toutefois avoir tord.

error-handlinghttp-status-codeshttp-errorhttp-status-code-400http-status-code-422
7
cessmestreet

Puis-je utiliser ces codes d'extension WebDAV pour gérer mes requêtes HTTP? Dans le cas de 422, puis-je l'utiliser même s'il ne fait pas partie des principaux codes HTTP.

HTTP est un protocole extensible et 422 est enregistré dans l'IANA , ce qui en fait un code d'état standard. Donc, rien ne vous empêche d'utiliser 422 dans votre application.

Dois-je utiliser 400 ou 422 pour mon erreur client?

Cela dépend, mais vous pouvez utiliser les deux. En général, utilisez 400 pour indiquer syntaxe des erreurs dans la charge utile ou des paramètres invalides dans l'URL. Et utilise 422 pour indiquer sémantique problèmes dans la charge utile.

À titre d'exemple, voir approche utilisé par GitHub v3 API :

Erreurs client

Il existe trois types d'erreurs client possibles sur les appels d'API qui reçoivent des corps de demande:

  1. L'envoi d'un JSON non valide entraînera un 400 Mauvaise réponse à la demande.

    HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

  2. L'envoi du mauvais type de valeurs JSON entraînera un 400 Mauvaise réponse à la demande.

    HTTP/1.1 400 Bad Request
Content-Length: 40

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

  3. L'envoi de champs non valides entraînera un 422 Réponse d'entité non traitable.

    HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

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

Choisir le plus approprié 4xx code d'état

Michael Kropat mettre en place un ensemble de tableaux de décision qui aide à déterminer le meilleur code d'état pour chaque situation. Voir ce qui suit pour 4xx codes d'état:

HTTP 4xx status codes

Détails du problème pour les API HTTP

Les codes d'état HTTP ne sont parfois pas suffisants pour transmettre suffisamment d'informations sur une erreur pour être utiles. RFC 7807 définit des formats de document JSON et XML simples pour informer le client d'un problème dans une API HTTP. C'est un excellent point de départ pour signaler des erreurs dans votre API.

Il définit également le application/problem+json et application/problem+xml types de supports.

18
cassiomolin