400 Bad Request semble maintenant être le meilleur code d'état HTTP / 1.1 pour votre cas d'utilisation.
Au moment de votre question (et de ma réponse d'origine), la RFC 7231 n'était pas une chose; auquel point je me suis opposé 400 Bad Request
parce que la RFC 2616 a dit (avec emphase la mienne):
La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe incorrecte .
et la demande que vous décrivez est un JSON syntaxiquement valide enfermé dans un HTTP syntaxiquement valide, et donc le serveur n'a aucun problème avec la syntaxe de la demande.
Cependant, comme l'a souligné Lee Saferite dans les commentaires , la RFC 7231, qui rend obsolète la RFC 2616, n'inclut pas cette restriction :
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).
Cependant, avant cette reformulation (ou si vous voulez ergoter sur le fait que la RFC 7231 n'est actuellement qu'une norme proposée ), 422 Unprocessable Entity
ne semble pas un code d'état HTTP incorrect pour votre cas d'utilisation, car comme le dit l'introduction de la RFC 4918:
Bien que les codes d'état fournis par HTTP / 1.1 soient suffisants pour décrire la plupart des conditions d'erreur rencontrées par les méthodes WebDAV, certaines erreurs ne tombent pas parfaitement dans les catégories existantes. Cette spécification définit des codes d'état supplémentaires développés pour les méthodes WebDAV (Section 11)
Et la description de422
dit:
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) ) le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues.
(Notez la référence à la syntaxe; je soupçonne que 7231 obsolète en partie 4918 aussi)
Cela ressemble exactement à votre situation, mais juste au cas où il y aurait un doute, il continue:
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.
(Remplacez "XML" par "JSON" et je pense que nous pouvons convenir que c'est votre situation)
Maintenant, certains objecteront que la RFC 4918 concerne les «extensions HTTP pour la création et la version distribuées sur le Web (WebDAV)» et que vous (vraisemblablement) ne faites rien impliquant WebDAV, vous ne devriez donc pas en utiliser les éléments.
Étant donné le choix entre l'utilisation d'un code d'erreur dans la norme d'origine qui ne couvre pas explicitement la situation, et celui d'une extension qui décrit exactement la situation, je choisirais cette dernière.
En outre, la section 21.4 de la RFC 4918 fait référence au registre de code d'état HTTP (Hypertext Transfer Protocol) de l' IANA , où se trouve 422.
Je propose qu'il soit tout à fait raisonnable pour un client ou un serveur HTTP d'utiliser n'importe quel code d'état de ce registre, tant qu'ils le font correctement.
Mais à partir de HTTP / 1.1, le RFC 7231 a une traction, alors utilisez-le 400 Bad Request
!