400 BAD demande la signification du code d'erreur HTTP?

J'ai une demande JSON que je poste sur une URL HTTP.

Doit-il être traité comme 400où le requestedResourcechamp existe mais "Roman"est une valeur non valide pour ce champ?

[{requestedResource:"Roman"}] 

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

[{blah:"Roman"}]

Un 400 signifie que la demande a été mal formée. En d'autres termes, le flux de données envoyé par le client au 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 je dirais correctement, utilisés pour indiquer que le JSON n'est pas valide d'une manière ou d'une autre selon les spécifications de l'API pour le service.

Selon cette logique, les deux scénarios que vous avez fournis devraient être de 400.

Imaginez plutôt qu'il s'agissait de XML plutôt que de JSON. Dans les deux cas, le XML ne passerait jamais la validation du schéma - soit à cause d'un élément non défini ou d'une valeur d'élément incorrecte. Ce serait une mauvaise demande. Même affaire ici.

Depuis w3.org

10.4.1 400 Mauvaise requête

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

La sélection d'un code de réponse HTTP est une tâche assez simple et peut être décrite par des règles simples. La seule partie délicate qui est souvent oubliée est le paragraphe 6.5 de la RFC 7231:

Sauf lorsqu'il répond à une demande HEAD, le serveur DEVRAIT envoyer une représentation contenant une explication de la situation d'erreur, et s'il s'agit d'une condition temporaire ou permanente.

Les règles sont les suivantes:

1. Si la demande a réussi, retournez le code 2xx (3xx pour la redirection). S'il y a eu une erreur de logique interne sur un serveur, retournez 5xx. S'il y a quelque chose de mal dans la demande du client, retournez le code 4xx.
2. Consultez le code de réponse disponible dans 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 revenir au code x00 (200, 400, 500). En cas de doute, retournez au code x00.
3. Renvoie la description de l'erreur dans le corps de la réponse. Pour les codes 4xx, il doit contenir suffisamment d'informations pour que le développeur client comprenne la raison et répare le client. Pour 5xx, pour des raisons de sécurité, aucun détail ne doit être révélé.
4. Si le client doit distinguer différentes erreurs et avoir des réactions différentes selon lui, définissez un format d'erreur lisible et extensible par machine et utilisez-le partout dans votre API. C'est une bonne pratique de le faire dès le début.
5. Gardez à l'esprit que le développeur client peut faire des choses étranges et essayer d'analyser les chaînes que vous renvoyez en tant que description lisible par l'homme. Et en changeant les chaînes, vous briserez ces clients mal écrits. Donc, fournissez toujours une description lisible par machine et essayez d'éviter de rapporter des informations supplémentaires dans le texte.

Donc, dans votre cas, j'ai renvoyé 400 erreurs et quelque chose comme ça si "Roman" est obtenu à partir de l'entrée utilisateur et le client doit avoir une 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 logique dans un client et n'est pas attendue, sauf si le développeur a fait quelque chose de mal:

{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}

Dans aucun des cas, la "syntaxe n'est mal formée". Ce sont les sémantiques qui ont tort. Par conséquent, à mon humble avis, un 400 est inapproprié. Au lieu de cela, il serait approprié de renvoyer un 200 avec une sorte d'objet d'erreur tel que { "error": { "message": "Unknown request keyword" } }ou autre.

Considérez le (s) chemin (s) de traitement client. Une erreur de syntaxe (par exemple, un JSON invalide) est une erreur dans la logique du programme, en d'autres termes un bug quelconque, et doit être traitée en conséquence, d'une manière similaire à un 403, par exemple; en d'autres termes, quelque chose de mal a mal tourné.

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

Par exemple, dans jQuery, je préférerais ne pas avoir à écrire un seul gestionnaire d'erreur qui traite à la fois des choses comme 500 et d'une erreur sémantique spécifique à l'application. D'autres frameworks, Ember pour un, traitent également les erreurs HTTP comme les 400 et 500 comme de grosses défaillances, obligeant le programmeur à détecter ce qui se passe et à se ramifier selon qu'il s'agit d'une "vraie" erreur ou non.

Utiliser des 400codes d'état à d'autres fins que d'indiquer que la demande est mal formée est tout simplement faux.

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

Le serveur refuse de traiter 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 demandée.

Si la charge utile de la demande est syntaxiquement correcte mais sémantiquement incorrecte, le 422code de réponse non standard peut être utilisé ou le 403code d'état standard :

Le serveur a compris la demande, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée.

Pensez aux attentes.

En tant qu'application cliente, vous vous attendez à savoir si quelque chose ne va pas du côté serveur. Si le serveur doit renvoyer une erreur lorsqu'il blahest manquant ou si la requestedResourcevaleur est incorrecte, une erreur 400 serait appropriée.

En complément, pour ceux qui pourraient rencontrer le même problème que le mien, j'utilise $.ajaxpour publier des données de formulaire sur le serveur et j'ai également eu l' 400erreur au début.

Supposons que j'ai une variable javascript,

var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 

N'utilisez pas de variable formDatadirectement comme valeur de clé datacomme 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); 
    }
});

Utilisez plutôt JSON.stringify pour encapsuler les éléments formDataci-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); 
    }
});

Quoi qu'il en soit, comme d'autres l'ont illustré, l'erreur est due au fait que le serveur n'a pas pu reconnaître la requête provoquant une syntaxe mal formée, je soulève simplement une instance à l'entraînement. J'espère que cela serait utile à quelqu'un.

Vérifiez d'abord l'URL, elle peut être erronée, si elle est correcte, vérifiez le corps de la demande que vous envoyez, la cause possible est que la demande que vous envoyez manque la syntaxe correcte.

Pour élaborer, recherchez les caractères spéciaux dans la chaîne de requête. S'il est (caractère spécial) utilisé, c'est la cause principale de cette erreur.

essayez de copier la demande et d'analyser chaque donnée de balise.