HTTP 400 (requête incorrecte) d'erreur logique, non malformé syntaxe de requête

Question

spécification HTTP / 1.1 (RFC 2616) a ceci à dire sur le sens de < a href = "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1"> code d'état 400, Bad Request (§10.4.1) :

La demande n'a pas pu être compris par le serveur en raison d'une syntaxe incorrecte. Le client ne doit pas répéter la demande sans modifications.

Il semble être une pratique générale parmi les quelques API basées sur HTTP ces jours-ci à utiliser 400 pour signifier une logique plutôt que syntaxe erreur avec une demande. Je suppose que les API font ce faire la distinction entre 400 (client-induite ) et 500 (induite par le serveur). Est-il acceptable ou incorrect d'utiliser 400 pour indiquer des erreurs non-syntaxique? Si elle est acceptable, est-il une référence annotée sur la RFC 2616 qui fournit une meilleure idée de l'utilisation prévue de 400?

Exemples:

• Google Data Protocol, protocole de référence, HTTP Codes d'état

Answer 1

En ce temps, le dernier projet de la spécification HTTPbis , qui est destiné à remplacer et faire la RFC 2616 obsolète, États :

Le code d'état 400 (Bad Request) indique que le serveur ne peut pas ou ne traitera pas la demande parce que la syntaxe reçue est invalide, aucun sens, ou dépasse une certaine limite à ce que le serveur est prêt à traiter.

Cette définition, alors que bien sûr encore soumis au changement, entérine la pratique largement utilisée de répondre à des erreurs logiques avec 400.

Answer 2

Statut 422 ( RFC 4918, Section 11.2 ) vient à l'esprit:

Le 422 code d'état (inexploitables entité) signifie que le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 (non pris en charge Type de support) est inappropriée), et la syntaxe de l'entité de requête est correcte (donc 400 (Bad Request) code d'état est inappropriée) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un organisme de requête XML contient bien formé (à savoir, syntaxiquement correct), mais sémantiquement erronée, des instructions XML.

Answer 3

HTTPbis permettra de résoudre le phrasé de 400 Bad Request afin qu'il couvre les erreurs logiques ainsi. Ainsi, 400 intégrera 422.

De https://tools.ietf.org/ html / draft-ietf-httpbis-p2-sémantique-18 # section 7.4.1
« Le serveur ne peut pas ou ne veut pas traiter la demande, en raison d'une erreur de client (par exemple, une syntaxe incorrecte) »

Answer 4

Même si, je l'ai utilisé pour représenter 400 erreurs logiques aussi, je dois dire que le retour 400 est faux dans ce cas, à cause de la façon dont se lit la spécification. Voici pourquoi je pense, l'erreur logique pourrait être qu'une relation avec une autre entité n'était ou non satisfait et apporter des modifications à l'autre entité pourrait faire exactement la même pour passer plus tard. Comme essayer de (complètement hypothétique) ajouter un employé en tant que membre d'un ministère lorsque cet employé n'existe pas (erreur logique). Ajout employé comme demande de membre pourrait échouer parce que l'employé n'existe pas. Mais la même demande exacte pourrait passer après que l'employé a été ajouté au système.

Juste mes 2 cents ... Nous avons besoin d'avocats et les juges pour interpréter la langue dans la RFC ces jours-ci:)

Merci, Vish

Answer 5

On pourrait faire valoir que d'avoir des données incorrectes dans votre demande une erreur de syntaxe, même si votre demande réelle au niveau HTTP (ligne de requête, en-têtes, etc.) est syntaxiquement valide.

Par exemple, si un service RESTful Web est documentée comme l'acceptation POSTs avec un XML personnalisé contenu Type de application/vnd.example.com.widget+xml, et vous envoyer à la place un texte ordinaire charabia ou un fichier binaire, il semble resasonable de traiter cela comme une erreur de syntaxe - votre corps de la requête ne sont pas sous la forme attendue.

Je ne sais pas de toutes les références officielles pour étayer cette thèse si, comme d'habitude, il semble être vers le bas pour interpréter la RFC 2616.

Mise à jour: Notez le libellé révisé RFC 7231 §6.5.1 :

Le 400 code d'état (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, la syntaxe de requête malformée, cadrage message de demande non valide, ou le routage de la demande trompeuse).

semble soutenir cet argument plus que le maintenant OBSOLETED RFC 2616 §10.4. 1 qui dit simplement:

La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe incorrecte. Le client ne doit pas répéter la demande sans modifications.

Answer 6

Sur les serveurs Java EE 400 est retourné si votre URL fait référence à un « -application web » inexistante. Est-ce une « erreur de syntaxe »? Cela dépend de ce que vous entendez par erreur de syntaxe. Je dirais que oui.

Les règles en anglais prescrire certaines relations entre les parties du discours. Par exemple « Bob Mary » est syntaxiquement correct, car il suit le modèle {Noun + Verbe + Noun}. Tandis que "Mariage Bob Mary" serait syntaxiquement incorrect, {Nom + Nom + Noun}.

La syntaxe d'un simple URLis {protocole +: + // + serveur +: + port}. Selon cette " http://www.google.com:80 " est syntaxiquement correct.

Mais qu'en est "abc: //www.google.com: 80"? Il semble suivre le même schéma exact. Mais réellement il est une erreur de syntaxe. Pourquoi? Parce que « abc » est pas un protocole défini.

Le point est que pour déterminer si oui ou non nous avons une situation 400 exige plus que l'analyse syntaxique des caractères et des espaces et délimiteurs. Il faut aussi reconnaître quelles sont les valides « parties du discours ».

Answer 7

est difficile.

Je pense que nous devrions;

1. Retour 4xx erreurs uniquement lorsque le client a le pouvoir de faire un changement à la demande, les en-têtes ou corps, qui aboutira à la demande suivante avec la même intention.

2. Codes de plage d'erreur de retour lorsque la mutation attendue n'a pas eu lieu, à savoir un SUPPRIMER n'a pas eu lieu ou un PUT n'a rien de changement. Cependant, un POST est plus intéressante car la spécification dit qu'il devrait être utilisé pour créer soit des ressources à un nouvel emplacement, ou tout simplement de traiter une charge utile.

En utilisant l'exemple dans la réponse de Vish, si la demande a l'intention d'ajouter employé Priya à un département marketing, mais Priya n'a pas été trouvé ou son compte est archivé, alors ceci est une erreur d'application.

La demande a bien fonctionné, il est arrivé à vos règles d'application, le client a fait tout correctement, les ETags adapté, etc., etc.

Parce que nous utilisons HTTP, nous devons répondre en fonction de l'effet de la demande sur l'état de la ressource. Et cela dépend de votre conception de l'API.

Peut-être que vous avez conçu ce sujet.

PUT { updated members list } /marketing/members

De retour un code de succès indiquerait que le « remplacement » de la ressource a travaillé; GET sur la ressource refléterait vos modifications, mais il ne serait pas.

Alors maintenant, vous devez choisir un code HTTP négatif approprié, et c'est la partie la plus délicate, puisque les codes sont fortement destinés au protocole HTTP, pas votre application.

Quand je lis les codes HTTP officiels, ces deux aspect approprié.

Le code d'état 409 (conflit) indique que la demande n'a pas pu être effectuée en raison d'un conflit avec l'état actuel de la ressource cible. Ce code est utilisé dans des situations où l'utilisateur pourrait être en mesure de résoudre le conflit et soumettre à nouveau la demande. Le serveur DEVRAIT générer une charge utile qui comprend suffisamment d'informations pour un utilisateur de reconnaître la source du conflit.

Le code d'état 500 (erreur interne du serveur) indique que le serveur a rencontré une condition inattendue qui l'a empêché de remplir la demande.

Bien que nous avons toujours considéré les 500 être comme une exception non gérée: - /

Je ne pense pas que son déraisonnable d'inventer votre propre code d'état tant que son application cohérente et conçu.

Cette conception est plus facile à traiter.

PUT { membership add command } /accounts/groups/memberships/instructions/1739119

Ensuite, vous pouvez concevoir votre API pour toujours réussir à créer l'instruction, il retourne 201 Créé et Emplacement en-tête et des problèmes avec l'instruction ont lieu dans ce nouveau ressource.

Un POST est plus comme cette dernière PUT vers un nouvel emplacement. Un POST permet de tout type de traitement du serveur d'un message, ce qui ouvre des dessins qui disent quelque chose comme « L'action a échoué avec succès. »

Vous avez probablement déjà écrit une API qui fait cela, un site Web. Vous postez le formulaire de paiement et il a été rejeté avec succès parce que le numéro de carte de crédit était mauvais.

Avec un POST, si vous revenez 200 ou 201 avec votre message de rejet dépend si une nouvelle ressource a été créé et est disponible pour GET à un autre endroit, ou non.

Avec tout ça dit, je serais enclin à concevoir des API qui ont besoin de moins PUT, peut-être juste mettre à jour les champs de données, et des actions et des choses qui Invoque les règles et le traitement ou tout simplement avoir une chance plus élevée d'échecs attendus, peut être conçu pour POST un formulaire d'instructions.