400 vs 422 réponse à L'affichage des données
j'essaye de comprendre ce que le code de statut correct renvoie sur différents scénarios avec une API" REST-like " sur laquelle je travaille. Disons que j'ai un point final qui permet de poster des achats au format JSON. Il ressemble à ceci:
{
"account_number": 45645511,
"upc": "00490000486",
"price": 1.00,
"tax": 0.08
}
Que dois-je déclarer si le client m'envoie" sales_tax "(au lieu de la"taxe" prévue). Actuellement, je rends un 400. Mais, j'ai commencé à questionner moi-même. Dois-je vraiment rendre un 422? Je c'est JSON (qui est supporté) et c'est JSON valide, c'est juste qu'il ne contient pas tous les champs requis.
9 réponses
400 Bad Request semblerait maintenant être le meilleur code de statut HTTP/1.1 pour votre cas d'utilisation.
au moment de votre question (et ma réponse originale), RFC 7231 n'était pas une chose; à ce moment-là, je me suis opposé à 400 Bad Request parce que RFC 2616 a dit (avec emphase sur le mien):
la requête ne pouvait pas être comprise par le serveur à cause de la malformation de la syntaxe .
et la requête que vous décrivez est syntaxiquement valide JSON encapsulée dans un HTTP syntaxiquement valide, et donc le serveur n'a aucun problème avec la syntaxe de la requête.
Toutefois comme l'a souligné Lee Saferite dans les commentaires , RFC 7231, qui obsolètes RFC 2616, ne comprend pas cette restriction :
le code D'état 400 (mauvaise requête) indique que le serveur ne peut pas ou ne veut pas traiter la requête en raison d'une erreur perçue par le client (par exemple, une syntaxe de requête mal formée, un cadrage de message de requête invalide ou un routage de requête trompeur).
cependant, avant cette nouvelle formulation (ou si vous voulez contester à propos de RFC 7231 étant seulement un proposé standard en ce moment), 422 Unprocessable Entity ne semble pas un incorrect code de statut HTTP pour votre cas D'utilisation, parce que comme l'introduction à la RFC 4918 dit:
alors que les codes D'état fournis par HTTP/1.1 sont suffisants pour décrire la plupart des conditions d'erreur rencontrées par les méthodes WebDAV, il certaines erreurs qui n'entrent dans les catégories existantes. Cette spécification définit les codes d'état supplémentaires développés pour WebDAV méthodes (Section 11)
et la description de 422 dit:
le code D'État 422 (Entité non traitable) désigne le serveur comprend le type de contenu de l'entité 415 (Type de média non pris en charge) code de statut est inapproprié), et le la syntaxe de l'entité requérante est correcte (donc a 400 (Mauvaise demande) code d'état inapproprié), mais n'a pas pu traiter le contenu instruction.
(noter la référence à la syntaxe; je soupçonne 7231 partiellement obsolètes 4918 aussi)
ça exactement comme votre situation, mais juste au cas où il n'y avait aucun doute, c'est-à-dire:
par exemple, cette condition d'erreur peut se produire si un XML du corps de la requête contient bien formé (c'est à dire, syntaxiquement correctes), mais instructions XML sémantiquement erronées.
(remplacer "XML" par "JSON" et je pense que nous pouvons convenir que c'est votre situation)
maintenant, certains objecteront que la RFC 4918 parle d '"Extensions HTTP pour la création et la Versioning distribuées sur le Web (WebDAV)" et que vous (probablement) ne faites rien impliquant WebDAV donc ne devrait pas utiliser des choses à partir de celui-ci.
compte tenu de la le choix entre l'utilisation d'un code d'erreur dans la norme d'origine explicitement que ne couvre pas la situation, et une extension qui décrit la situation exactement, je choisirais ce dernier.
de plus, RFC 4918 Section 21.4 renvoie au IANA Hypertext Transfer Protocol (HTTP) Status code Registry , où 422 peut être trouvé.
je propose QU'il soit tout à fait raisonnable pour un HTTP client ou serveur pour utiliser n'importe quel code d'état de ce registre, tant qu'ils le font correctement.
mais à partir de HTTP/1.1, RFC 7231 a la traction, donc il suffit d'utiliser 400 Bad Request !
pour tenir compte du statut à compter de 2015:
Behaviorally les codes de réponse 400 et 422 seront traités de la même façon par les clients et les intermédiaires, de sorte qu'en fait, il ne fait pas une concrète différence que vous utilisez.
cependant, je m'attendrais à voir 400 actuellement utilisé plus largement, et en outre les clarifications que le HTTPbis spec fournit le plus approprié des deux codes d'état:
- la spécification HTTPbis clarifie l'intention de 400 de ne pas être uniquement pour des erreurs de syntaxe. La phrase plus large "indique que le serveur ne peut pas ou ne veut pas traiter la requête en raison de quelque chose qui est perçu comme une erreur du client" est maintenant utilisée.
- 422 est spécifiquement une extension WebDAV, et n'est pas référencé dans la RFC 2616 ou dans la nouvelle Spécification HTTPbis .
pour le contexte, HTTPbis est une révision de la spécification HTTP/1.1 qui tente de clarifier les zones qui sont imprécises ou incohérentes. Une fois qu'il aura atteint le statut approuvé, il remplacera la RFC 2616.
400 Bad Request est le code D'état HTTP approprié pour votre cas D'utilisation. Le code est défini par HTTP / 0.9-1.1 RFC.
la requête n'a pas pu être comprise par le serveur en raison d'une erreur syntaxe. Le client ne doit pas répéter la demande sans modification.
http://tools.ietf.org/html/rfc2616#section-10.4.1
422 Entité non traitable est défini par RFC 4918 - WebDav. Notez qu'il y a une légère différence par rapport à 400, voir texte cité ci-dessous.
cette condition d'erreur peut se produire si un XML du corps de la requête contient bien formé (c'est à dire, syntaxiquement correctes), mais instructions XML sémantiquement erronées.
pour garder l'interface uniforme vous devriez utiliser 422 seulement dans un cas de réponses XML et vous devriez également soutenez tous les codes d'état définis par l'extension Webdav, pas seulement 422.
http://tools.ietf.org/html/rfc4918#page-78
Voir aussi Mark Nottingham post sur les codes d'état:
c'est une erreur d'essayer de mapper chaque partie de votre application "profondément" dans les codes de statut HTTP; dans la plupart des cas le niveau de granularité vous vouloir viser est beaucoup plus grossier. dans le doute, C'est bon. utiliser les codes d'état génériques 200 OK, 400 Bad Request et 500 interne Erreur de Service lorsqu'il n'y a pas de meilleure correspondance .
il n'y a pas de réponse correcte, car cela dépend de la définition de" syntaxe " pour votre requête. La chose la plus importante est que vous:
- utilisez le(S) code (s) de réponse de façon constante
- incluez autant d'informations supplémentaires dans le corps de réponse que vous pouvez pour aider le(s) développeur (s) à utiliser votre API pour comprendre ce qui se passe.=
avant que tout le monde saute sur moi pour avoir dit qu'il n'y avait pas bonne ou mauvaise réponse ici, laissez-moi vous expliquer un peu comment j'en suis arrivé à la conclusion.
dans cet exemple précis, la question de L'OP concerne une requête JSON qui contient une clé différente de celle attendue. Maintenant, le nom clé reçu est très similaire, du point de vue du langage naturel, à la clé attendue, mais il est, strictement, différent, et donc pas (habituellement) reconnu par une machine comme étant équivalent.
comme je l'ai dit plus haut, le facteur déterminant est ce signifie syntaxe . Si la requête a été envoyée avec un type de contenu application/json , alors oui, la requête est syntaxiquement valide parce que c'est une syntaxe JSON valide, mais pas sémantiquement valide, car il ne correspond pas à ce qui est attendu. (en supposant une définition stricte de ce qui rend la requête en question sémantiquement valide ou non).
si, par contre, la demande a été envoyée avec une indication plus précise type de contenu personnalisé comme application/vnd.mycorp.mydatatype+json qui, peut-être, spécifie exactement quels champs sont attendus, alors je dirais que la requête pourrait facilement être syntaxiquement invalide, d'où la réponse 400.
dans le cas en question, puisque la clé était erronée, et non la valeur , il y avait une syntaxe erreur s'il y avait une spécification pour ce que les clés valides sont. si il n'y avait pas de spécification pour les clés valides, ou l'erreur était avec une valeur , alors ce serait une erreur sémantique .
tout d'Abord c'est une très bonne question.
400 Bad Request - Quand un élément essentiel de l'information est manquante à partir de la demande
p.ex. en-tête d'autorisation ou en-tête de type de contenu. Ce qui est absolument requis par le serveur pour comprendre la requête. Cela peut différer d'un serveur à l'autre.
422 Unprocessable de l'Entité Lorsque le corps de la requête ne peut pas être analysée.
400. La requête a atteint le serveur. Le serveur a accusé réception de la requête et la structure de base est correcte. Mais l'information dans le corps de la demande ne peut pas être analysée ou comprise.
p.ex. Content-Type: application/xml lorsque le corps de la requête est JSON.
voici un article énumérant les codes de statut et son utilisation dans les API REST. https://metamug.com/article/status-codes-for-rest-api.php
422 Entité Non Traitable Expliquée Mise À Jour: 6 Mars 2017
Qu'Est-Ce Que 422 Unprocessable Entity?
un code de statut 422 se produit quand une requête est bien formée, cependant, dû les erreurs sémantiques ne peuvent pas être traitées. Ce statut HTTP était introduit dans la RFC 4918 et est plus spécifiquement orienté vers HTTP extensions pour la création et la version Web (WebDAV).
il est une certaine controverse sur si oui ou non les développeurs devrait retourner une erreur 400 vs 422 aux clients (plus sur les différences entre les deux statuts ci-dessous). Cependant, dans la plupart des cas, il est convenu sur ce, le statut 422 ne doit être retourné que si vous supportez WebDAV capacité.
une définition mot à mot du code de statut 422 tirée de la section 11.2 dans la RFC 4918 peut être lu ci-dessous.
L'422 (Unprocessable Entité) statut le code signifie le serveur comprend le type de contenu de l'entité 415 (Type de média non pris en charge) code de statut est inapproprié), et le la syntaxe de l'entité de requête est correcte (donc une 400 (mauvaise requête) code d'état inapproprié), mais n'a pas pu traiter le contenu instruction.
la définition poursuit en disant:
par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient bien formé (c'est à dire, syntactiquement correct), mais sémantiquement instructions XML erronées.
400 vs 422 Codes D'État
les erreurs de mauvaise requête utilisent le code d'état 400 et devraient être renvoie au client si la syntaxe de la requête est mal formée, contient le cadrage de message de requête invalide, ou le routage de requête trompeur. Ce code de statut peut sembler assez similaire au 422 unprocessable statut de l'entité, cependant, un petit morceau d'information que la syntaxe d'une entité de requête pour un 422 erreur est correcte alors que la syntaxe d'une requête qui génère une erreur 400 est incorrecte.
l'utilisation du statut 422 ne doit être réservée qu'à des cas très particuliers cas d'utilisation. Dans la plupart des autres cas où une erreur du client s'est produite pour la syntaxe malformée, le statut 400 Bad Request doit être utilisé.
Votre cas: HTTP 400 est le bon code de statut pour votre affaire de REPOS perspective que sa syntaxe incorrecte à envoyer sales_tax au lieu de tax , si c'est un JSON valide. Ceci est normalement appliqué par la plupart des cadres latéraux du serveur lors de la mise en correspondance des JSON avec des objets. Cependant, il y a quelques implémentations REST qui ignorent la nouvelle key dans l'objet JSON. Dans ce cas, une spécification content-type personnalisée pour n'accepter que des champs valides peut être appliqué par le côté serveur.
scénario idéal pour 422:
dans un monde idéal, 422 est préférable et généralement acceptable à envoyer comme réponse si le serveur comprend le type de contenu de l'entité de requête et la syntaxe de l'entité de requête est correcte mais n'a pas été capable de traiter les données parce que son sémantiquement erroné.
Situations de plus de 400 ans 422:
rappelez-vous, le code de réponse 422 est un code D'état HTTP étendu (WebDAV). Il y a encore quelques clients HTTP / bibliothèques front-end qui ne sont pas prêts à gérer 422. Pour eux, C'est aussi simple que "HTTP 422 est erroné, parce que ce N'est pas HTTP" . Du point de vue du service, 400 n'est pas très précis.
dans l'architecture d'entreprise, les services sont déployés principalement sur des couches de services comme SOA, IDM, etc. Ils servent généralement plusieurs clients allant d'un client natif très ancien à un client HTTP récent. Si L'un des clients ne gère pas HTTP 422, les options sont que demander au client de mettre à jour ou de changer votre code de réponse en HTTP 400 pour tout le monde. Dans mon expérience, c'est très rare de nos jours, mais encore une possibilité. Ainsi, une étude minutieuse de votre architecture est toujours nécessaire avant de décider des codes de réponse HTTP.
pour gérer une situation comme celle-ci, le les couches de service utilisent normalement le drapeau versioning ou setup configuration pour les clients de conformité HTTP stricte pour envoyer 400, et envoyer 422 pour le reste d'entre eux. De cette façon, ils fournissent un support de rétrocompatibilité pour les consommateurs existants, mais en même temps fournissent la possibilité pour les nouveaux clients de consommer HTTP 422.
la dernière mise à jour de RFC7321 dit:
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
cela confirme que les serveurs peuvent envoyer HTTP 400 pour une requête invalide. 400 ne se réfère plus seulement à l'erreur de syntaxe , cependant, 422 est toujours une réponse authentique à condition que les clients peuvent le gérer.
étude de Cas: GitHub API
https://developer.github.com/v3/#client-errors
peut-être copier à partir D'APIs bien connus est une idée sage:
il existe trois types possibles d'erreurs client sur les appels API qui reçoivent des corps de requête:
L'envoi de JSON non valide entraînera une réponse de demande erronée de 400.
HTTP/1.1 400 Bad Request Content-Length: 35 {"message":"Problems parsing JSON"}envoyer le mauvais type de valeurs JSON résultera en une mauvaise réponse de requête de 400.
HTTP/1.1 400 Bad Request Content-Length: 40 {"message":"Body should be a JSON object"}L'envoi de champs invalides entraînera une réponse de 422 Entity non traitable.
HTTP/1.1 422 Unprocessable Entity Content-Length: 149 { "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ] }
vous devez en fait retourner" 200 OK " et dans le corps de réponse inclure un message sur ce qui s'est passé avec les données publiées. Alors c'est à votre application de comprendre le message.
le truc c'est que les codes de statut HTTP sont exactement les codes de statut HTTP. Et ceux-ci sont censés avoir un sens seulement à la couche transport, pas à la couche application. La couche application ne devrait jamais savoir que HTTP est utilisé. Si vous avez changé votre couche de transport de HTTP aux Pigeons voyageurs, elle ne devrait pas affecter votre couche d'application de quelque manière que ce soit.
Permettez-moi de vous donner un exemple non-virtuel. Disons que tu tombes amoureux d'une fille et qu'elle t'aime en retour, mais que sa famille déménage dans un pays complètement différent. Elle vous donne sa nouvelle adresse postale. Naturellement, vous décidez de lui envoyer une lettre d'amour. Si vous écrivez votre lettre, le mettre dans une enveloppe, écrire son adresse sur l'enveloppe, mettre un timbre sur elle et l'envoyer. Maintenant, considérons ces scénarios
- vous avez oublié d'écrire un nom de rue. Vous recevrez une lettre de retour non ouverte avec un message écrit dessus disant que l'adresse est mal formée. Vous avez foiré la demande et le bureau de poste n'est pas en mesure de la traiter. C'est l'équivalent de recevoir "400 Bad Request".
- ainsi vous fixez l'adresse et envoyez la lettre à nouveau. Mais en raison de la malchance vous avez mal orthographié le nom du rue. Vous obtiendrez la lettre de retour avec un message disant que l'adresse n'existe pas. C'est l'équivalent de recevoir "404 Not Found".
- Vous fixer l'adresse de nouveau et cette fois, vous parvenez à écrire correctement l'adresse. Votre fille reçoit la lettre et vous répond. C'est l'équivalent de recevoir "200 OK". Toutefois, cela ne signifie pas que vous allez aimer ce qu'elle a écrit dans sa lettre. Cela signifie simplement qu'elle a reçu votre message et a une réponse pour vous. Tant que tu n'as pas ouvert l'enveloppe et lu sa lettre, tu ne peux pas savoir si tu lui manques ou si elle veut rompre avec toi.
en bref: retourner "200 OK" ne signifie pas que l'application serveur a de bonnes nouvelles pour vous. Cela signifie seulement qu'il a des nouvelles.
PS: le code de statut 422 a une signification seulement dans le contexte de WebDAV. Si vous ne travaillez pas avec WebDAV, alors 422 a exactement la même signification standard que n'importe quel autre code non standard = qui est nul.