Quel code de réponse d’état HTTP dois-je utiliser si la requête ne contient pas un paramètre requirejs?

Je pense à 412 (Precondition Failed) mais il y a peut-être un meilleur standard?

Le statut 422 semble le plus approprié en fonction des spécifications .

Le code de statut 422 (Entité impossible à traiter) signifie que le serveur comprend le type de contenu de l’entité de demande (par conséquent, un code d’état 415 (Type de support non pris en charge) est inapproprié) et la syntaxe de l’entité de requête est correcte ) le code d’état est inapproprié) mais n’a pas pu traiter les instructions contenues. 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.

Ils déclarent que xml malformé est un exemple de mauvaise syntaxe (appelant un 400). Une chaîne de requête mal formée semble analogue à cela, donc 400 ne semble pas approprié pour une chaîne de requête bien formée qui manque un paramètre.

UPDATE @DavidV indique correctement que cette spécification concerne WebDAV, et non le kernel HTTP. Mais certaines API populaires non WebDAV utilisent de toute façon 422, faute d’un meilleur code de statut ( voir ceci ).

Je ne suis pas sûr qu’il y ait une norme fixe, mais j’aurais utilisé 400 Bad Request :

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

L’ API WCF dans .NET gère les parameters manquants en renvoyant une erreur HTTP 404 “Endpoint Not Found” lors de l’utilisation de webHttpBinding .

Le 404 Not Found peut avoir un sens si vous considérez le nom de votre méthode de service Web ainsi que sa signature de paramètre. Autrement dit, si vous exposez une méthode de service Web LoginUser(ssortingng, ssortingng) et que vous demandez LoginUser(ssortingng) , cette dernière est introuvable.

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, sont introuvables.

10.4.5 404 Introuvable

Le serveur n’a rien trouvé correspondant à l’URI de demande. Aucune indication n’est donnée quant à savoir si la condition est temporaire ou permanente.

Le 400 Bad Request , comme Gert l’a suggéré , rest un code de réponse valide, mais je pense qu’il est normalement utilisé pour indiquer des problèmes de niveau inférieur. Il peut facilement être interprété comme une requête HTTP mal formée, peut-être des en-têtes HTTP manquants ou non valides, ou similaires.

10.4.1 400 Mauvaise demande

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

Dans l’un de nos projets d’API, nous décidons de définir un statut 409 sur une requête, lorsque nous ne pouvons pas le remplir à 100% à cause d’un paramètre manquant.

HTTP Status Code “409 Conflict” a été pour nous un bon essai, car sa définition nécessite d’inclure suffisamment d’informations pour que l’utilisateur reconnaisse la source du conflit.

Référence: w3.org/Protocols/

Ainsi, parmi d’autres, comme 400 ou 404, nous avons choisi 409 pour imposer le besoin de consulter certaines notes de la requête pour créer une nouvelle demande.

Quoi qu’il en soit, c’était particulier parce que nous devions envoyer des données si la demande n’était pas complètement correcte, et nous devons forcer le client à regarder le message et à 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 paramètre 400 et un tableau manquant. Mais lorsque nous avons besoin d’envoyer plus d’informations, comme un message d’affaire particulier et que nous voulons être plus sûrs que le client s’en occupe, nous envoyons un message 409

Vous pouvez envoyer un code 400 Bad Request. C’est l’un des codes d’état 4xx les plus généraux, vous pouvez donc l’utiliser pour signifier ce que vous avez l’intention de faire: le client envoie une demande pour laquelle il manque des informations / parameters nécessaires à son application.

J’ai l’habitude d’aller pour 422 (Entité non traitable) si quelque chose dans les parameters requirejs ne correspond pas à celui requirejs par le sharepoint terminaison de l’API (mot de passe trop court), mais pour 406 (Inacceptable).

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 fausses). 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. S’il s’agit d’une réponse JSON ou XML, les informations d’erreur s’y trouvent.

De rfc2616 :

10.4.4 403 Interdit

Le serveur a compris la demande, mais refuse de la satisfaire.
L’autorisation ne va pas aider 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 souhaitait
public pourquoi la demande n’a pas été remplie, il DEVRAIT décrire la raison 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.

On pourrait faire valoir qu’un 404 Not Found devrait être utilisé car la ressource spécifiée n’a pas pu être trouvée.

Pour les personnes intéressées, Spring MVC (au moins 3.x) renvoie un 400 dans ce cas, ce qui me semble erroné.

J’ai testé plusieurs URL Google (accounts.google.com) et supprimé les parameters requirejs, et ils renvoient généralement un 404 dans ce cas.

Je copierais Google.

J’irais avec un 403.

De RFC 2616 – Hypertext Transfer Protocol – HTTP / 1.1

403 Interdit

Le serveur a compris la demande, mais refuse de la satisfaire. L’autorisation ne va pas aider 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 souhaitait rendre publique la raison pour laquelle la demande n’a pas été satisfaite, il DEVRAIT décrire la raison 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 devez décrire la raison de l’échec dans votre réponse. Si vous préférez ne pas le faire, utilisez simplement 404.