Supposons d'avoir un HTTP POST qui accepte comme entrée un JSON avec quelques données et il doit valider ces données. La méthode doit également renvoyer un message de validation dans le corps de la réponse.
Ex.
{
"A" : 1,
"B" : 1,
"C" : 3
}
Supposons que certaines règles de validation soient définies sur le JSON, par exemple (A + B ) doit être inférieur au paramètre C.
J'ai des doutes sur le code d'état HTTP.
Mais dans le cas où le JSON est valide (il y a tous les paramètres demandés et les types sont corrects) mais que les paramètres ne respectent pas les règles définies (A + B Est-il nécessaire de différencier le statut HTTP du statut des règles de validation? Cheers
3 Réponses :
Tout dépend du cas d'utilisation / de la fonctionnalité que vous souhaitez atteindre.
Si vous voulez faciliter le travail des autres avec des messages valides, je retournerais peut-être 2xx uniquement si le message est complètement valide, et dans tous les autres cas renvoie 4xx . Dans ce cas, l'appelant n'a pas besoin d'analyser le résultat, ce qui facilite le travail.
Si le cas d'utilisation est de fournir un service d'analyse que d'autres utiliseront pour analyser les messages, pas spécifiquement pour utiliser le message lui-même, alors je retournerais 2xx avec le résultat de l'analyse à moins que le le message ne peut pas être analysé (pas un json par exemple), auquel cas 4xx est garanti.
Merci pour votre suggestion, il est également important de séparer le statut HTTP du statut Business Logic que vous implémentez.
votre réponse doit être 400 avec le message suivant: "Mauvaise demande: les paramètres ne respectent pas les règles". Erreur 400
C'est pour cela que le code d'état 422 ("Entité non traitable") a été conçu.
Voir https://www.greenbytes.de/tech/webdav/ rfc4918.html # STATUS_422 .