Quel est le code d'état HTTP approprié à renvoyer par un service API REST en cas d'échec de la validation?
Je retourne actuellement 401 Unauthorized chaque fois que je rencontre un échec de validation dans mon application d'API (Django / Piston ) REST. Après avoir jeté un coup d'œil au Registre d'état HTTP Je ne suis pas convaincu qu'il s'agisse d'un code approprié pour un échec de validation, que recommandez-vous?
- 400 mauvaise demande
- 401 non autorisé
- 403 interdit
- 405 Méthode non autorisée
- 406 pas acceptable
- 412 précondition a échoué
- 417 Échec de l'attente
- 422 entités non traitables
- 424 Dépendance échouée
Mise à jour : "Échec de la validation" ci-dessus signifie un échec de la validation des données au niveau de l'application, c'est-à-dire une date/heure spécifiée de manière incorrecte, une adresse électronique fictive, etc.
Si "échec de la validation" signifie qu'il y a une erreur du client dans la demande, utilisez HTTP 400 (demande incorrecte). Par exemple, si l'URI est censé avoir une date ISO-8601 et que son format est incorrect ou qu'il fait référence au 31 février, vous renverriez un HTTP 400. La même chose si vous attendez du XML bien formé dans un corps d'entité et il ne parvient pas à analyser.
(1/2016): Au cours des cinq dernières années, le plus spécifique HTTP 422 (Unprocessable Entity) de WebDAV est devenu une alternative très raisonnable au HTTP 400. Voir, par exemple, son utilisation dans JSON API . Mais notez que HTTP 422 a pas en HTTP 1.1, RFC-7231 .
Richardson et Ruby's RESTful Web Services contient un appendice très utile sur l'utilisation des différents codes de réponse HTTP. Ils disent:
400 (“Requête incorrecte”)
Importance: élevée.
Il s'agit de l'état d'erreur générique côté client, utilisé lorsqu'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 dans le bon format, mais cela n’a aucun sens. (p. 381)
et:
401 ("non autorisé")
Importance: élevée.
Le client a tenté d’opérer sur une ressource protégée sans fournir les informations d’authentification appropriées. Il peut avoir fourni les informations d'identification erronées, ou aucune. Les informations d'identification peuvent être un nom d'utilisateur et un mot de passe, une clé API ou un jeton d'authentification, quelles que soient les attentes du service en question. Il est courant pour un client de faire une demande d’URI et d’accepter une adresse 401 afin de savoir quel type d’informations d’authentification doit être envoyé et dans quel format. [...]
Tiré de la RFC 4918 (et également documenté à l'adresse http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):
Le code de statut 422 (entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de demande (par conséquent, un code de statut 415 (type de support non pris en charge) est inapproprié), et la syntaxe de l'entité de demande est correcte (par conséquent, une requête de type 400 (requête incorrecte)). ) le 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 corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.
Un duplicata dans la base de données doit être un 409 CONFLICT.
Je recommande d'utiliser 422 UNPROCESSABLE ENTITY pour les erreurs de validation.
Je donne une explication plus longue des codes 4xx ici: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/
C'est ici:
rfc2616 # section-10.4.1 - 400 requêtes incorrectes
La requête n'a pas pu être comprise par le serveur en raison de syntaxe malformée. Le client NE DEVRAIT PAS répéter la demande sans modifications.
rfc7231 # section-6.5.1 - 6.5.1. 400 mauvaise requête
Le code d’état 400 (demande incorrecte) indique que le serveur ne peut pas ou ne traitera pas la demande en raison d’une erreur perçue par le client (par exemple, syntaxe de demande malformée, message de demande non valide cadrant ou acheminement de demande trompeur) .
Fait référence à des cas mal formés (pas bien formés)!
rfc4918 - 11.2. 422 Entité non traitable
Le code de statut 422 (entité non traitable) signifie que le serveur
comprend le type de contenu de l’entité de la demande (un code d’état 415 (type de support non supporté) est donc inapproprié), et le la syntaxe de l’entité de la demande est correcte (donc un Le code d'état de la demande) est inapproprié) 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 bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées, XML.
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 à sémantiquement erroné - Pensez à quelque chose comme la validation "Ce nom d’utilisateur existe déjà".
400 n'est pas utilisé correctement pour la validation d'objet
Je dirais que techniquement, il ne s’agit peut-être pas d’un échec HTTP, car la ressource était (supposément) validement spécifiée, l’utilisateur était authentifié et il n’y avait pas d’échec opérationnel (toutefois, même les spécifications incluent des codes réservés, tels que 402 Payment Requed qui ne sont pas disponibles. t à proprement parler lié à HTTP non plus, bien qu’il soit peut-être souhaitable de l’avoir au niveau du protocole afin que tout périphérique puisse reconnaître la condition).
Si tel est le cas, j’ajouterais un champ d’état à la réponse contenant des erreurs d’application, comme
<status> <code> 4 </ code> <message> La plage de dates n'est pas valide </ message> </ status>
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 support factuel.
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, un XML mal formé)?
Si tel est le cas, je dirais que 400 demandes incorrectes est probablement la bonne chose, mais sans savoir ce que vous êtes en train de "valider", il est impossible de le dire.