réponse de 400 vs 422 au poste des données

Question

Je suis à essayer de comprendre ce que le bon code d'état de revenir sur les différents scénarios avec un "reste" comme de l'API que je suis en train de travailler sur. Disons que j'ai un point de fin qui permet de POST avec des achats au format JSON. Il ressemble à ceci:

{
    "account_number": 45645511
    "upc": "00490000486"
    "price": 1.00
    "tax": 0.08
}

Que dois-je de retour si le client envoie-moi "sales_tax" (à la place de la "taxe"). Actuellement, je suis de retour d'un 400. Mais, j'ai commencé à questionner moi-même. Je devrais vraiment retourner une 422? Je veux dire, c'est du JSON (qui est pris en charge) et c'est JSON valide, c'est juste ne pas contenir tous les champs requis.

Answer 1

422 Unprocessable Entité est le bon code d'état HTTP de votre cas d'utilisation.

Plusieurs cadres de l'utilisation de 400 Bad Request; ils le font de manière incorrecte. Pour citer la RFC 2616 (l'emphase est mienne):

La demande ne peut pas être comprise par le serveur en raison de la malformation de la syntaxe.

La demande que vous décrivez est syntaxiquement valide JSON enfermé dans syntaxiquement valide l'adresse HTTP. Le serveur n'a pas de problèmes avec la syntaxe de la requête.

L'introduction de la RFC 4918 dit:

Alors que l'état les codes fournis par HTTP/1.1 sont suffisantes pour décrire la plupart des conditions d'erreur rencontrées par WebDAV méthodes, il y certaines erreurs qui n'entrent dans les catégories existantes. Cette spécification définit extra codes de statut élaboré pour WebDAV méthodes (Section 11)

Cela semble beaucoup comme une erreur qui n'est pas "entrent dans les catégories existantes" comme décrit dans la RFC 2616.

En regardant la description de l' 422:

Les 422 (Unprocessable Entité) code du statut signifie que le serveur comprend le type de contenu de la demande de l'entité (d'où une 415(Unsupported Media Type) code d'état est inapproprié), et le la syntaxe de l'entité de la requête est correcte (donc un 400 (Bad Request) le code d'état est inapproprié), mais a été incapable de traiter le contenu de l' les instructions.

Cela sonne 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 sémantiquement erronée, instructions XML.

(Remplacer "XML" avec "JSON" et je pense que nous pouvons convenir à votre situation)

Maintenant, certains objecteront que la RFC 4918 est sur "Extensions HTTP pour le Web Distributed Authoring and Versioning (WebDAV)" et que vous avez (sans doute) sont à ne rien faire de impliquant WebDAV et donc ne devrait pas utiliser des choses.

Étant donné le choix entre l'utilisation d'un code d'erreur dans la norme d'origine explicitement ne couvre pas votre situation, et une extension qui décrit la situation exactement, je choisirais ce dernier.

En outre, RFC 4918 Article 21.4 se réfère à l' IANA Protocole de Transfert Hypertexte (HTTP) Code d'État du Registre, où 422 peut être trouvé.

Je propose qu'il est totalement raisonnable pour un client HTTP ou serveur à utiliser tous les codes de statut à partir de ce registre, aussi longtemps qu'ils le font correctement.

Answer 2

400 Bad Request est bon code d'état HTTP de votre cas d'utilisation. Ce code est défini par HTTP/0.9-1.1 RFC.

La demande ne peut pas être comprise par le serveur en raison de la malformation de la syntaxe. Le client ne DOIT PAS répéter la demande sans les modifications.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 Unprocessable Entité est défini par la RFC 4918 - WebDav et vous devez utiliser ce code uniquement si vous prenez en charge les fonctionnalités WebDav. Ce code ne fait pas partie de l'adresse HTTP/x RFC. Notez qu'il y a une légère différence en comparaison à 400, voir le 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 sémantiquement erronée, instructions XML.

http://tools.ietf.org/html/rfc4918#page-78

Answer 3

Il n'y a pas de bonne réponse, car il dépend de ce que la définition de la "syntaxe" est pour votre demande. La chose la plus importante est que vous:

1. Utilisez le code de réponse(s) régulièrement
2. Inclure autant d'informations supplémentaires dans le corps de la réponse que vous pouvez pour aider le développeur(s) à l'aide de votre API comprendre ce qui se passe.=

Avant tout le monde saute sur moi pour dire qu'il n'y a pas de bonne ou mauvaise réponse ici, laissez-moi vous expliquer un peu comment j'en suis venu à la conclusion.

Dans cet exemple précis, l'OP est question au sujet d'un JSON demande qui contient une clé différente de celle attendue. Maintenant, le nom de la clé reçue est très similaire, à partir d'un langage naturel point de vue, la clé, mais il est, à proprement parler, différents, et donc de ne pas (généralement) reconnus par une machine comme étant équivalent.

Comme je l'ai dit ci-dessus, le facteur décisif est ce qui est signifié par la syntaxe. Si la demande a été envoyée à un Type de Contenu de application/json, alors oui, la demande est syntaxiquement valide parce que c'est JSON valide la syntaxe, mais pas sémantiquement valide, car ils ne correspondent pas à ce qui est prévu. (en supposant une définition stricte de ce qui fait la demande en question sémantiquement valide ou non).

Si, d'autre part, la demande a été envoyée avec un plus spécifiques Type de Contenu personnalisé comme application/vnd.mycorp.mydatatype+json que, peut-être, précise exactement ce que les champs sont attendus, alors je dirais que la demande pourrait facilement être syntaxiquement invalide, d'où le 400 de réponse.

Dans le cas en question, car la clef était mauvais, pas de la valeur, il y a une syntaxe d'erreur si il y avait un cahier des charges pour ce qui valide les touches sont. Si il n'y a pas de spécification pour les clés valides, ou l'erreur a été d'une valeur, alors ce serait une sémantique de l' erreur.