400 BAD request code d'erreur HTTP sens?

J'ai un JSON demande qui je suis l'affichage d'une URL HTTP.

Cela devrait-il être traité comme 400 où requestedResource champ existe, mais "Roman" est une valeur non valide pour ce domaine?

[{requestedResource:"Roman"}]

Cela devrait-il être traité comme 400 où "blah" champ n'existe pas du tout?

[{blah:"Roman"}]

Peut-être que 402, si ils veulent vraiment être en mesure d'envoyer la valeur Roman, ils ont juste besoin de payer plus 🙂
Un véritable scénario où je l'ai vu - j'ai fait un appel de PUT ajouter des données. J'ai fait un appel de put de nouveau en utilisant le même corps de la requête et a obtenu un 400 qui m'a dit qu'une demande antérieure est déjà traitée. Ses normal que notre système afin de prendre un peu de temps pour ajouter des données.

InformationsquelleAutor Phoenix | 2013-10-29

350

400 signifie que la demande a été mal formé. En d'autres termes, le flux de données envoyé par le client pour le serveur n'a pas suivi les règles.

Dans le cas d'une API REST avec une charge utile JSON, 400 sont généralement, et bien, je dirais, utilisé pour indiquer que le JSON n'est pas valide d'une certaine façon en fonction de la spécification de l'API pour le service.

Par cette logique, tant les scénarios que vous avez fournie devraient être 400.

Imaginer à la place de ce ont été XML plutôt que JSON. Dans les deux cas, le XML ne serait jamais passer la validation du schéma, soit à cause d'un élément indéfini ou une mauvaise valeur de l'élément. Ce serait un mauvais demande. Même problème ici.
- Je suis d'accord avec vous jusqu'à "Par cette logique, tant les scénarios que vous avez fournie devraient être 400." Je ne pense pas que le contenu du JSON devrait avoir de l'importance ici. Quand vous dites malformés, je voudrais croire qu'elle aborde les questions dans le format des données que vous envoyez, par exemple, si vous passez d'un champ dans le JSON, vous devriez obtenir 400.
- Il y a un bon set de REPOS codes de réponse à restapitutorial.com/httpstatuscodes.html. Il peut aussi dépendre de la façon dont vous souhaitez gérer une demande valide comme une 406 (Non Acceptable) ou 405 method not allowed. Cependant, 400 est appropriée parce que "La requête n'a pas pu être comprise par le serveur en raison de la malformation de la syntaxe. Le client ne DOIT PAS répéter la demande sans modification."
- Donc "La requête n'a pas pu être comprise par le serveur en raison de la malformation de la syntaxe" peut être demande (par exemple, l'un des en-têtes HTTP en cours de malformé) ou le données porté par la demande (par exemple, une valeur JSON manquant)?
- Vidya dit "le XML ne serait jamais passer la validation du schéma". Le Point étant que les parseurs XML distinction entre un document bien formé (c'est à dire du point de vue syntaxique du son) et valide (c'est à dire du point de vue sémantique du son, par exemple, selon un schéma). La description de l'400 code est "la requête n'a pas pu être comprise par le serveur en raison de la malformation de syntaxe" - de sorte qu'il ne devrait pas être utilisé pour les erreurs de validation, à mon humble avis.
- href="http://stackoverflow.com/questions/42851301/get-http-400-bad-request-ionic-2" title="http get 400 bad request ionique 2">stackoverflow.com/questions/42851301/... jetez un oeil à cette erreur, je suis également confrontés à la même question similaire à cette erreur si vous savez, merci de m'aider
InformationsquelleAutor Vidya
71

De w3.org

10.4.1 400 Bad Request

La demande n'a pas pu ê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.
- L'exactitude de retourner une erreur 400 n'est pas basé sur un champ vs une valeur, mais la demande dans son ensemble. Je pense que HTTP 400 est un bon moyen de faire
- Voulez-vous dire qu'un 400 de réponse être utilisé pour dire à vos clients que quoi que ce soit, c'est à dire l'url, en-têtes, corps, etc., dans la demande pourrait être mauvais et pas seulement le corps ?
- bien pour les url, le code correct est 404, pour les en-têtes, j'imagine que c'est un toss up, 403 (interdit) semble être la bonne façon de faire si les en-têtes sont de rejet de l'identité, mais que faire si les en-têtes sont de déterminer le format de sortie? sur le seul chemin, je pense, se sent le droit pour 400 est dans la situation où une action est demandée qui ne fait pas de sens et ne doit pas être répété. J'ai écrit cette réponse il y a 4 ans, ces jours-ci je me sens comme même les erreurs de retour de 200, et que les erreurs ne devraient s'appliquer à la transmission de http et pas la charge utile.
- Cette réponse, couvre beaucoup de cela, mais je n'ai pas lu tous les graphiques encore stackoverflow.com/a/34324179/16959
- les équilibreurs de charge, les procurations et les autres middleware souvent utiliser les codes d'état à l'aide de l'itinéraire, rapport & réparation. heureusement, des codes comme "422" sont expressément au sujet de la charge utile, donc il y a de la place dans la spécification pour la charge utile des codes d'état.
InformationsquelleAutor Jason Sperske
50

De la sélection d'un code de réponse HTTP est tout à fait une tâche facile et ne peuvent être décrites par des règles simples. La seule partie délicate qui est souvent oublié, c'est le paragraphe 6.5 de la RFC 7231:

Sauf au moment de répondre à une requête HEAD, le serveur DOIT envoyer un
représentation avec une explication de la situation d'erreur,
et si elle est temporaire ou permanente de la condition.

Règles sont les suivantes:
1. Si la demande a été un succès, puis retour 2xx (code 3xx pour rediriger). Si il y a une logique interne erreur sur un serveur, puis retour 5xx. Si il n'y a rien de mal à la demande du client, puis retour code 4xx.
2. Regarder à travers disponible code de réponse de la catégorie sélectionnée. Si l'un d'eux a un nom qui correspond bien à votre situation, vous pouvez l'utiliser. Sinon, il suffit de secours à x00 code (200, 400, 500). Si vous en doutez, secours à x00 code.
3. Retour description de l'erreur dans le corps de la réponse. Pour 4xx codes, il doit contenir suffisamment d'informations pour développeur client à comprendre la raison et de fixer le client. Pour 5xx pour des raisons de sécurité aucun détail ne doit être révélé.
4. Si le client a besoin de distinguer les différentes erreurs et ont un effet différent selon elle, de définir lisible à la machine et extensible erreur de format et de l'utiliser partout dans votre API. Il est de bonne pratique de faire à partir de début.
5. Gardez à l'esprit que développeur client peut faire des choses étranges et d'essayer d'analyser les chaînes qui vous revenir en tant que description lisible par l'homme. Et en changeant les chaînes de vous briser le mal écrites de clients. Afin de toujours fournir lisibles à la machine description et essayez d'éviter de rapporter des informations supplémentaires dans le texte.
Donc dans votre cas, je serais retourné erreur 400 et quelque chose comme si ce "Roman" est obtenu à partir de la saisie de l'utilisateur et le client doit disposer d'réaction spécifique:
```
{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"
}
```
ou une erreur plus générique, si une telle situation est une mauvaise erreur de logique dans un client et n'est pas prévu, à moins que le développeur fait quelque chose de mal:
```
{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}
```
InformationsquelleAutor Alexey Guseynov
20

Dans les deux cas, est la syntaxe "mal formé". C'est la sémantique qui est faux. Donc, à mon humble avis un 400 est inapproprié. Au lieu de cela, il conviendrait de revenir un 200 avec une sorte d'objet d'erreur comme { "error": { "message": "Unknown request keyword" } } ou quoi que ce soit.

Considèrent le client de traitement de chemin(s). Une erreur dans la syntaxe (par exemple, invalid JSON) est une erreur dans la logique du programme, en d'autres termes d'un bug de la sorte, et devraient être traités en conséquence, dans une manière semblable à une 403, dire; en d'autres termes, quelque chose de mauvais s'est mal passé.

Une erreur dans la valeur d'un paramètre, d'autre part, est une erreur de sémantique, peut-être dû à dire mal validé la saisie de l'utilisateur. Ce n'est pas une erreur HTTP (bien que je suppose que cela pourrait être un 422). Le traitement serait différent.

Par exemple, en jQuery, je préférerais ne pas avoir à écrire une seule gestionnaire d'erreur, qui traite à la fois des choses comme les 500 et quelques spécifiques à l'application erreur sémantique. D'autres cadres, la Braise pour un, également traiter les erreurs HTTP, comme 400 et 500 à l'identique comme big fat échecs, nécessitant le programmeur à détecter ce qui se passe et de la direction générale selon qu'il est un "vrai" erreur ou pas.
- +1, Le P en HTTP est synonyme de Protocole et si la réponse est une erreur HTTP, ce doit être un problème de bas niveau. J'ai évité beaucoup de code de la complexité au fil des années, en utilisant l'approche décrite par torazaburo. Il y aurait moins de douleur dans le RESTE de la terre, si nous avons tous écrit résilients code au lieu de si souvent exploser avec les erreurs HTTP.
- 200 signifie que la demande a été traitée, donc normal succès logique doit être exécuté sur un client. Ici nous avons certainement une erreur, donc la réponse ne peut pas avoir 2xx ou 3xx code. Il ne peut pas être 5xx, soit parce que c'est une erreur du côté serveur et nous avons une erreur sur le côté client. De sorte que doit être une erreur 4xx. Mais la description de l'erreur dans le corps de la réponse est une bonne chose à faire, et c'est en fait une façon conseillé par la spécification HTTP.
- 422 est mieux, pour les bûcherons, les procurations et les autres outils
InformationsquelleAutor
14

À l'aide de 400 les codes d'état pour tout autre but que d'indiquer que la demande est mal formé est tout simplement faux.

Si la demande de la charge utile contient un octet de la séquence qui n'a pas pu être analysée comme application/json (si le serveur s'attend à ce que format), le code d'état est 415:

Le serveur refuse de service à la demande, car l'entité de
la demande est dans un format non pris en charge par la ressource demandée pour
la méthode de la requête.

Si la demande de la charge utile est syntaxiquement correct, mais sémantiquement incorrect, le non-standard 422 code de réponse peuvent être utilisées, ou la norme 403 code d'état:

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é.
- non, 415 est pour quand l'entité est revendiquée pour être de type incorrect par exemple image/gif au lieu de text/json dans le Content-Type: en-tête. - sans doute, ceci est aussi valable si un composant de type multipart, qui a le mauvais type spécifié, voir tools.ietf.org/html/rfc4918 où il traite de 422 pour une discussion plus approfondie,
InformationsquelleAutor Cochise Ruhulessin
7

Penser attentes.

En tant que client de l'app, vous vous attendez à savoir si quelque chose va mal sur le côté serveur. Si le serveur doit lever une erreur lors de l' blah est manquant ou le requestedResource valeur est incorrecte qu'une erreur 400 serait approprié.

InformationsquelleAutor film42
3

D'abord de vérifier l'URL, il peut se tromper, si elle est correcte, vérifier le corps de la requête qui vous envoient, la cause possible est la demande que vous envoyez est manquant droit de la syntaxe.

D'élaborer , de vérifier les caractères spéciaux dans la chaîne de demande. Si c'est (char spécial) utilisé c'est la cause de cette erreur.

essayer de la copie de la demande et à l'analyse de chaque et toutes les données des balises.
- J'ai été prise en erreur http 400, j'ai vérifié ma demande a certains caractères spéciaux. Pour corriger cela, j'ai passé le charset=UTF-8 dans le type de contenu.
InformationsquelleAutor Ankur Bhutani
2

Comme un complément, pour ceux qui pourraient rencontrer le même problème que le mien, je suis en utilisant $.ajax pour valider les données du formulaire au serveur et j'ai aussi eu la 400 erreur au premier abord.

Supposons que j'ai une variable javascript,
```
var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 
```
Ne pas utiliser de variable formData directement comme valeur de clé data comme ci-dessous:
```
$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});
```
Au lieu de cela, l'utilisation de JSON.stringify à encapsuler les formData comme ci-dessous:
```
$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});
```
De toute façon, comme d'autres l'ont illustré, l'erreur est parce que le serveur n'a pas pu reconnaître la demande de cause la malformation de la syntaxe, je suis juste lever un exemple à la pratique. Espérons qu'il serait utile à quelqu'un.

InformationsquelleAutor Eugene

Vous devez vous connecter pour publier un commentaire.