Je crée une fonctionnalité de mon application Web où un utilisateur peut "éditer-in-place" un enregistrement et soumettre le formulaire via Ajax à l'aide de jQuery.
Lorsque quelqu'un est "AJAX EDITION", un enregistrement et ils soumettent le formulaire avec des données valides, j'envoie un code de statut 200, qui déclenche la fonction de réussite JQuery Ajax, puis ignore le corps de réponse (puisqu'il a réussi, je ne réussis pas y avez besoin de cela) et réduisez le formulaire.
Lorsqu'il y a des erreurs de validation de formule, j'envoie un code d'état 400 pour déclencher la méthode d'erreur de jQuery et dans le corps de la demande, je spécifie les champs ne validant pas.
Dans une précédente question Stackoverflow, quelqu'un a mentionné qu'il "semblait étrange" que j'envoie un code de statut de 400 et travaille avec le corps de réponse. Mon approche n'est-elle pas une meilleure pratique? Que recommanderiez-vous que je fais dans cette situation?
3 Réponses :
Pour moi, les codes d'état HTTP sont destinés à signaler à la couche HTTP, et non à la couche d'application. Je dirais que la réponse appropriée aux mauvaises données correctement soumises (si vous voyez ce que je veux dire) est de 200 avec un code d'erreur de couche d'application. J'utilise Json pour cela. Mes demandes récupèrent toujours un petit message JSON, qui a toujours un drapeau indiquant le succès / l'échec au niveau de l'application. Mes wrappers pour les appels Ajax connaissent à ce sujet et envoient le cas échéant.
bon point. Ainsi, votre type JSON est comme ceci: {Succès: 0, HTML: 'Messages d'erreur va ici'}
@Andrew: Oui ou {"Erreur": ""} sur le succès et {"Erreur": "Non séquitur. Vos faits sont non coordonnés."} sur erreur. Ensuite, mon code côté client est si (message.error) {/ * ... Signaler une erreur * /}
Je ne suis pas d'accord. Dans les interfaces de style de repos, les codes de réponse sont pour la signalisation de niveau d'application. Pensez aux opérations de CRUD où vous revenez. Dis 201 Créé sur un post. Dans ce cas, un 400 n'est pas un mauvais moyen de signaler des données incorrectement formatées.
Cela signifierait abuser de HTTP comme un tunnel. Ne pas.
@ Julien: http est un tunnel pour mes applications. Je n'écris pas un client WebDAV ou un serveur. De plus, l'ensemble défini des codes de réponse ne couvre pas la gamme complète d'erreurs pour une application (par opposition à un localisateur de ressources / fournisseur) et, tandis que La spécification dit spécifiquement qu'ils sont extensibles et pour que je puisse utiliser 471 pour signifier« vos faits sont non coordonnés », je suis réticent à faire confiance à chaque lien Dans la chaîne se comporter correctement, "doit" dans la spécification ou non.
HI @ T.J.Crowder - Quelle coïncidence de voir votre nom pour la deuxième fois aujourd'hui, mais pour un sujet totalement différent. Je viens de poster une question similaire à celle-ci, ici . J'ai un peu partagez votre point de vue sur ce problème, mais je ne peux toujours pas me décider. Pouvez-vous s'il vous plaît commenter dessus quand vous aurez une chance? Merci.
Je retournerais 200 avec une page d'erreur (application) ou la page d'origine avec une option d'erreur, qui déclenche un panneau d'information avec la description d'erreur.
La raison en est que les codes d'erreur HTTP sont destinés à la réponse du navigateur sur le serveur Web, non pour votre application Web. Gardez votre logique d'application distincte de ce qui se passe lorsque le navigateur et le serveur se parlent les uns des autres.
Considérez que vous avez votre application principale, qui contient à son tour deux applications: 1. Une application JS entière qui consommera votre deuxième application. 2. Une API qui sera consommée par votre demande JS. Pourquoi ne pas utiliser de codes de réponse HTTP pour gérer le succès ou les rappels d'erreur? Et si plus de clients commencent à consommer votre deuxième application?, Si tel était le cas et que vous avez commencé à envoyer correctement les codes de réponse HTTP du début, vous n'auriez pas besoin de refactoriser les réponses de votre API. Mon point ici est qu'il ne fait pas de mal d'utiliser différents codes de réponse HTTP. Qu'est-ce que tu penses?
Utilisation de la charge utile d'un code d'état 4xx est tout simplement bien. Il n'y a rien dans la spécification HTTP en disant autrement.
Si vous voulez quelque chose de plus spécifique que 400, consultez 422 entité non traitée < / a>.
Les codes d'état sont vraiment destinés à communiquer des métadonnées sur la demande entre client et serveur, non entre l'application et le serveur.
422 est également une extension WebDAV au protocole HTTP, ne faisant pas partie du protocole d'origine. Il ne serait pas logique d'utiliser ce code d'état avec un service WebDAV.
IMO Utilisation des codes 4xx d'erreur pour les erreurs de validation est correcte en termes de spécifications HTTP. Cependant, de nombreuses bibliothèques JS Bibliothèques supposent que vous retournerez 200 et sur 4xx, ils sont comme "c'est Fubar-ed, rentrons à la maison.". Par exemple, PJAX affichera le contenu uniquement s'il est livré avec le code de réussite. L'envoi de codes d'erreur appropriés a toujours été une lutte de montée dans mon expérience. Maintenant, je suis penché vers l'envoi d'erreurs de validation avec le code 200.
J'utilise 409 pour les erreurs de validation: - "Ce code n'est autorisé que dans des situations où il est prévu que l'utilisateur puisse pouvoir résoudre le conflit et soumettre à nouveau la demande" restapitaly.com/httpstatuscodes.html