Quel code de réponse d'état HTTP dois-je utiliser si la requête manque un paramètre requis?

Question

Je pense 412 (Échec de la précondition), mais il pourrait y avoir une meilleure norme?

Answer 1

Statut 422 semble la plus adéquate basée sur la spec.

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. 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.

Ils affirment que xml mal formé est un exemple de mauvaise syntaxe (appel pour une 400). Un mal formé chaîne de requête semble analogue à ce, afin de 400 ne semble pas approprié pour un bien formé la chaîne de la requête est manquant un param.

Mise à JOUR @DavidV souligne à juste titre que cette spécification est pour WebDAV, pas de noyau de HTTP. Mais certains populaire non-WebDAV sont des Api à l'aide de 422 de toute façon, faute de mieux, le code d'état (voir ceci).

Answer 2

Je ne suis pas sûr qu'il existe un standard défini, mais j'aurais utilisé 400 Bad Request :

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

Answer 3

La WCF API .NET poignées de paramètres manquants en retournant un HTTP 404 "point de Terminaison introuvable" erreur lors de l'utilisation de la webHttpBinding.

L' 404 Not Found peut être utile si vous considérez votre méthode de service web nom, ainsi que son paramètre de signature. C'est, si vous exposer une méthode de service web LoginUser(string, string) et vous demande LoginUser(string), ce dernier n'est pas trouvé.

En gros, cela signifie que la méthode de service web que vous appelez, en collaboration avec le paramètre de signature que vous avez spécifié ne peut être trouvé.

10.4.5 404 Not Found

Le serveur n'a pas trouvé quelque chose correspondant à l'URI de Demande. Pas de indication de savoir si la condition est temporaire ou permanente.

L' 400 Bad Request, comme Gert suggéré, reste un code de réponse valide, mais je pense qu'il est normalement utilisé pour indiquer le niveau inférieur des problèmes. Il pourrait facilement être interprété comme une demande HTTP incorrecte, peut-être manquant ou invalide les en-têtes HTTP, ou similaire.

10.4.1 400 Bad Request

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.

Answer 4

Vous pouvez envoyer un code 400 Bad Request. C'est l'un des codes d'état 4xx plus généraux, vous pouvez donc l'utiliser pour signifier ce que vous avez l'intention de faire: le client envoie une requête qui manque des informations / paramètres dont votre application a besoin pour la traiter correctement.

Answer 5

J'utilise souvent une erreur 403 Forbidden. Le raisonnement est que la demande a été comprise, mais je ne vais pas faire comme demandé (parce que les choses sont mal). L'entité de réponse explique ce qui est mal, donc si la réponse est une page HTML, les messages d'erreur sont dans la page. Si c'est un JSON ou XML de réponse, les informations d'erreur est là.

À partir de la rfc2616:

10.4.4 403 Forbidden

Le serveur a compris la requête, mais refuse de la satisfaire.
L'autorisation ne sera pas l'aide et de la demande ne DOIT PAS être répété.
Si la méthode de la requête n'a pas été la TÊTE et le serveur souhaite faire
public pourquoi la demande n'a pas été remplies, il DOIT décrire le la raison pour le refus de l'entité. Si le serveur ne souhaite pas rendre cette information disponible pour le client, le code d'état 404
(Pas Trouvé) peut être utilisé à la place.