Quel est le code d'état HTTP approprié à renvoyer par un service d'API REST en cas d'échec de validation?


394

Je retourne actuellement 401 non autorisé chaque fois que je rencontre un échec de validation dans mon application API REST basée sur Django / Piston . Après avoir jeté un œil au registre des codes d'état HTTP, je ne suis pas convaincu qu'il s'agit d'un code approprié pour un échec de validation, que recommandez-vous tous?

  • 400 Mauvaise demande
  • 401 non autorisé
  • 403 Interdit
  • 405 Méthode non autorisée
  • 406 Non acceptable
  • Échec de la condition préalable 412
  • 417 Attente a échoué
  • 422 Entité non traitable
  • 424 Dépendance défaillante

Mise à jour : "Échec de validation" ci-dessus signifie un échec de validation des données au niveau de l'application, c'est-à-dire une date / heure incorrectement spécifiée, une adresse e-mail fausse, etc.


2
Découvrez cette réponse: stackoverflow.com/a/2657624/221612
Kenny Meyer

3
Fwiw, le lien de Kenny suggère le code 422, comme le fait maintenant la réponse de Jim ci - dessous . #TheMoreYouKnow #SavingYouAClick
ruffin

Je pense que 401 est plus clair.
insigne

Réponses:


298

Si «échec de validation» signifie qu'il y a une erreur client dans la demande, utilisez HTTP 400 (Bad Request). Par exemple, si l'URI est censé avoir une date ISO-8601 et que vous trouvez qu'il est dans le mauvais format ou fait référence au 31 février, alors vous renverriez un HTTP 400. Idem si vous vous attendez à un XML bien formé dans un corps d'entité et il ne parvient pas à analyser.

(1/2016): Au cours des cinq dernières années , HTTP 422 (Entité non traitable) plus spécifique de WebDAV est devenu une alternative très raisonnable à HTTP 400. Voir par exemple son utilisation dans l' API JSON . Mais notez que HTTP 422 n'est pas devenu HTTP 1.1, RFC-7231 .

Les services Web RESTful de Richardson et Ruby contiennent une annexe très utile sur le moment d'utiliser les différents codes de réponse HTTP. Ils disent:

400 («mauvaise demande»)
Importance: élevée.
Il s'agit de l'état d'erreur côté client générique, utilisé lorsque aucun autre code d'erreur 4xx n'est approprié. Il est couramment utilisé lorsque le client soumet une représentation avec une demande PUT ou POST, et que la représentation est au bon format, mais cela n'a aucun sens. (p. 381)

et:

401 («non autorisé»)
Importance: élevée.
Le client a tenté de fonctionner sur une ressource protégée sans fournir les informations d'authentification appropriées. Il a peut-être fourni des informations d'identification erronées, voire aucune. Les informations d'identification peuvent être un nom d'utilisateur et un mot de passe, une clé API ou un jeton d'authentification, quel que soit le service en attente. Il est courant qu'un client fasse une demande d'URI et accepte un 401 juste pour qu'il sache quel type d'informations d'identification envoyer et sous quel format. [...]


3
Mais probablement si le format URI n'est pas valide, un 404 pourrait être plus approprié.
manu

11
Comme indiqué par @ReWrite, je pense également que 422 est meilleur pour les erreurs de validation.
panteo

11
Je dirais que c'est faux. 400 Bad Request est utilisé lorsqu'il y a un problème de syntaxe avec la demande. Je dirais que ReWrite a raison de recommander 422 qui concerne le contenu de la demande.
Stijn de Witt

3
@Kenji yes, 401 («Unauthorized»): «Il a peut-être fourni des informations d'identification incorrectes ...» signifie un utilisateur et / ou un mot de passe incorrects.
razzintown

4
Les erreurs @JimFerrans 400 sont pour lesquelles la syntaxe donnée est incorrecte. Les erreurs 401 sont spécifiques si j'essaie d'accéder à une page à laquelle je dois être connecté pour y accéder et je ne suis pas du tout connecté. Les erreurs 422 concernent la syntaxe correcte, mais le serveur refuse le service. Un nom d'utilisateur / mot de passe incorrect est une syntaxe correcte (pas une erreur 400) et je n'essaie pas d'accéder à une page pour laquelle je dois être connecté car j'accède à la page de connexion elle-même (pas une erreur 401). L'erreur 401 devrait être utilisée pour quelque chose comme une page de paramètres à laquelle seul un utilisateur peut accéder
Zachary Weixelbaum

98

De RFC 4918 (et également documenté à http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

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


6
Je recommanderais 422 - Entité non traitable pour les échecs de validation de plus de 400 - Mauvaise demande
java_geek


19

C'est ici:

rfc2616 # section-10.4.1 - 400 mauvaise requête

La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe incorrecte . Le client NE DEVRAIT PAS répéter la demande sans modifications.

rfc7231 # section-6.5.1 - 6.5.1. 400 Mauvaise demande

Le code d'état 400 (Bad Request) 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, une syntaxe de demande incorrecte, un cadrage de message de demande invalide ou un routage de demande trompeur) .

Fait référence aux cas mal formés (pas bien formés)!

rfc4918 - 11.2. 422 Entité non traitable

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

Conclusion

Règle générale: [_] 00 couvre le cas le plus général et les cas qui ne sont pas couverts par le code désigné.

422 correspond à la meilleure erreur de validation d'objet (précisément ma recommandation :)
Quant à la sémantique erronée - Pensez à quelque chose comme la validation "Ce nom d'utilisateur existe déjà".

400 est incorrectement utilisé pour la validation d'objet


9

Je dirais que techniquement, il pourrait ne pas s'agir d'un échec HTTP, car la ressource a été (vraisemblablement) validement spécifiée, l'utilisateur a été authentifié et il n'y a pas eu d'échec opérationnel (cependant, même la spécification comprend certains codes réservés comme 402 Payment Required qui ne sont pas '' t à proprement parler lié à HTTP non plus, mais il pourrait être judicieux de l'avoir au niveau du protocole pour que tout appareil puisse reconnaître la condition).

Si c'est effectivement le cas, j'ajouterais un champ d'état à la réponse avec des erreurs d'application, comme

<status><code>4</code> <message> La plage de dates n'est pas valide </message> </status>


1

Il y a un peu plus d'informations sur la sémantique de ces erreurs dans RFC 2616 , qui documente HTTP 1.1.

Personnellement, j'utiliserais probablement 400 Bad Request, mais ce n'est que mon opinion personnelle sans aucun soutien factuel.


0

Qu'entendez-vous exactement par «échec de validation»? Que validez-vous? Faites-vous référence à quelque chose comme une erreur de syntaxe (par exemple, XML mal formé)?

Si c'est le cas, je dirais que 400 Bad Request est probablement la bonne chose, mais sans savoir ce que vous "validez", c'est impossible à dire.


que se passe-t-il si nous essayons de valider une validation ou des règles métier.
Metalhead
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.