Quel code de réponse HTTP dois-je utiliser si un paramètre requis manque à la requête?
je pense 412 (condition préalable échoué) mais il pourrait y avoir une meilleure norme?
10 réponses
statut 422 semble le plus approprié basé sur le spec .
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é de requête est correcte (donc une 400 (mauvaise requête) code d'état inapproprié), mais n'a pas pu traiter le contenu instruction. 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.
ils déclarent que le xml malformé est un exemple de mauvaise syntaxe (appelant un 400). Une chaîne de requête mal formée semble analogue à ceci, donc 400 ne semble pas approprié pour une chaîne de requête bien formée qui manque un param.
UPDATE @DavidV souligne à juste titre que cette spécification est pour WebDAV, pas pour le HTTP de base. Mais certains API non-WebDAV populaires utilisent de toute façon 422, faute d'un meilleur code de statut ( voir ce ).
Je ne suis pas sûr qu'il y ait une norme établie, mais j'aurais utilisé 400 Bad Request :
la requête ne peut être comprise par le serveur à cause d'une mauvaise syntaxe. Le client ne doit pas répéter demande sans modifications.
le WCF API dans .NET gère les paramètres manquants en retournant une erreur HTTP 404 " Endpoint Not Found", en utilisant le webHttpBinding .
le 404 Not Found peut avoir du sens si vous considérez votre nom de méthode de service web avec sa signature de paramètre. C'est-à-dire, si vous exposez une méthode de service web LoginUser(string, string) et que vous demandez LoginUser(string) , cette dernière n'est pas trouvée.
Fondamentalement, cela signifierait que la méthode de service web que vous appelez, ainsi que la signature de paramètre que vous avez spécifiée, ne peut pas être trouvée.
10.4.5 404 Not Found
le serveur n'a rien trouvé qui corresponde à L'URI de la requête. Aucun indication de savoir si la condition est temporaire ou permanent.
le 400 Bad Request , comme Gert suggéré , reste code de réponse VALIDE, mais je pense qu'il est normalement utilisé pour indiquer des problèmes de niveau inférieur. Il pourrait facilement être interprété comme une requête HTTP mal formée, peut-être des en-têtes HTTP manquants ou invalides, ou similaire.
10.4.1 400 Bad Request
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.
J'opte habituellement pour 422 (entité non traitable) si quelque chose dans les paramètres requis ne correspond pas à ce que le paramètre requis de L'API (comme un mot de passe trop court) mais pour un paramètre manquant j'opte pour 406 (inacceptable).
dans l'un de nos projets API, nous décidons de définir un statut 409 pour une requête, lorsque nous ne pouvons pas la remplir à 100% à cause d'un paramètre manquant.
code de statut HTTP "conflit 409" était pour nous un bon essai parce que c'est la définition doivent inclure suffisamment d'information pour que l'utilisateur puisse reconnaître la source du conflit.
référence: w3.org/Protocols /
So parmi d'autres réponses comme 400 ou 404 nous avons choisi 409 pour renforcer la nécessité de regarder sur certaines notes dans la demande utile pour mettre en place une nouvelle et bonne demande.
de toute façon notre cas il était particulier parce que nous devons envoyer des données eve si la demande n'était pas complètement correcte, et nous devons forcer le client à regarder le message et de comprendre ce qui ne va pas dans la demande.
en général si nous avons seulement un paramètre manquant nous allons pour un 400 et un tableau de paramètre manquant. Mais quand nous avons besoin d'envoyer plus d'informations, comme un cas particulier de message, et nous voulons être plus sûr que le client prendra soin de nous envoyer un 409
vous pouvez envoyer un code de demande erroné 400. C'est l'un des codes de statut 4xx à usage plus général, donc vous pouvez l'utiliser pour signifier ce que vous avez l'intention: le client envoie une demande qui manque des informations/Paramètres que votre application nécessite afin de la traiter correctement.
j'utilise souvent un 403 erreur interdite. 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 ne va pas, donc si la réponse est une page HTML, les messages d'erreur sont dans la page. Si c'est une réponse JSON ou XML, l'information d'erreur est là.
à Partir de rfc2616 :
10.4.4 403 Interdit
Le serveur a compris la requête, mais refuse de la satisfaire.
L'autorisation n'aidera pas et la demande ne doit pas être répétée.
Si la méthode de requête N'était pas HEAD et que le serveur souhaite faire
public pourquoi la demande n'a pas été satisfaite, elle doit décrire la raison pour le refus de l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, code d'état 404
(Pas Trouvé) peut être utilisé à la place.
on pourrait faire valoir qu'un 404 Not Found devrait être utilisé puisque la ressource spécifiée n'a pas pu être trouvée.
Pour ceux intéressés, Spring MVC, paragraphe 3.x au moins) retourne un 400 dans ce cas, ce qui me semble erroné.
j'ai testé plusieurs URLs Google (accounts.google.com) et supprimé les paramètres requis, et ils renvoient généralement un 404 dans ce cas.
Je copierais Google.
je dirais un 403.
à Partir de RFC 2616 - Protocole de Transfert Hypertexte -- HTTP/1.1
403 Interdit
Le serveur a compris la requête, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande ne doit pas être répétée. Si la méthode de requête N'était pas HEAD et que le serveur souhaite rendre publique la raison pour laquelle la requête n'a pas été satisfait, il doit décrire le motif du refus dans l'entité. Si le serveur ne souhaite pas mettre ces informations à la disposition du client, le code d'état 404 (non trouvé) peut être utilisé à la place.
vous devriez décrire la raison de l'échec dans votre réponse. Si vous préférez ne pas le faire, utilisez simplement le 404.