Bon codes d'état pour les réponses JSON pour les appels Ajax?

Mon projet est de retour JSON pour les appels Ajax à partir du navigateur. Je me demande quel est le code de statut est pour l'envoi de retour avec des réponses non valides (mais géré avec succès) les soumissions de données.

Par exemple, jQuery a la suite de deux rappels lors de la prise de requêtes Ajax:

success: Déclenché lorsqu'un 200/2xx code d'état est livré avec la réponse.

error: Déclenché lorsque 4xx, 5xx, etc, codes de statut, de revenir avec la réponse.

Si un utilisateur tente de créer un nouveau "Personne" objet, je l'ai renvoyer une représentation JSON de l'objet nouvellement créé, en cas de succès, donnant ainsi accès javascript pour la nécessaire ID unique pour le nouvel objet, etc. Ceci, bien sûr, est envoyé avec un code d'état 200.

Si un utilisateur soumet malformé ou des données non valides (par exemple, un invalide ou incomplète champ "nom"), je tiens à envoyer les messages d'erreur de validation via JSON. (Je ne vois pas pourquoi ce serait une mauvaise chose).

Ma question est: en agissant de la sorte, dois-je envoyer un 200 code d'état, parce que j'ai traité avec succès leurs données non valides? Donc, je serais à l'aide de jQuery success de rappel, mais simplement de vérifier pour les erreurs...

Ou, dois-je utiliser un 4xx code d'état, peut-être que "Bad Request", parce que les données qu'ils m'ont envoyé n'est pas valide? (et donc, utiliser l' error de rappel à faire le nécessaire côté client notifications).

  • Je suis au courant et certain qu'il y a plus de détails que les explications simples que je vous ai donné les causes de jQuery pour tirer les rappels que j'ai mentionnés. Juste essayer de garder ma compréhension des descriptions courtes et simples.
InformationsquelleAutor anonymous coward | 2011-02-16
  1. 14

    Je suis d'accord avec les 400 Bad Request réponse.

    Pour l'inspiration, vous pourriez avoir un oeil à la façon de Twitter (largement utilisé JSON service) est-ce que:
    https://dev.twitter.com/overview/api/response-codes

    Code Text Description

    • 200 OK - Succès!
    • 304 Not Modified - Il n'y a pas de nouvelles données de retour.
    • 400 Bad Request - La demande n'était pas valide ou ne peut pas en être autrement servi. Accompagnement d'un message d'erreur s'expliquer davantage. Les demandes sans authentification sont considérés comme invalides et le rendement de cette réponse.
    • 401 Unauthorized - Manquante ou incorrecte des données d'authentification. Également retourné dans d'autres circonstances (par exemple, tous les appels à l'API v1 points de terminaison de retour 401).
    • 403 Forbidden - La demande est entendu, mais elle a été refusée ou l'accès n'est pas autorisé. Accompagnement d'un message d'erreur s'expliquer pourquoi. Ce code est utilisé lorsque des demandes sont refusées en raison de la mise à jour des limites . D'autres raisons de cet état d'être renvoyés sont répertoriés avec les codes de réponse dans le tableau ci-dessous.
    • 404 Not Found - L'URI demandée n'est pas valide ou que la ressource demandée, par exemple un utilisateur, n'existe pas. Également renvoyé lorsque le format demandé n'est pas pris en charge par la méthode de la requête.
    • 406 Not Acceptable - Renvoyé lorsqu'un format non valide est spécifié dans la requête.
    • 410 Gone - Cette ressource est allé. Utilisé pour indiquer qu'une API d'extrémité a été désactivé.
    • 420 Enhance Your Calm Renvoyée lorsqu'une application est limitée par la vitesse .
    • 422 Unprocessable Entity - Renvoyée lorsqu'une image téléchargée sur compte postal /update_profile_banner est incapable de traiter.
    • 429 Too Many Requests - Renvoyée lorsqu'une demande ne peut pas être servi en raison de l'application de la limite de taux ayant été épuisées pour la ressource. Voir La Limitation Du Débit .
    • 500 Internal Server Error = Quelque chose est cassé. Veuillez poster sur les forums des développeurs avec plus de détails de votre demande, dans le cas où d'autres utilisateurs ont des problèmes similaires.
    • 502 Bad Gateway - Twitter est en panne ou mise à niveau.
    • 503 Service Unavailable - Twitter pour les serveurs sont up, mais surchargé de demandes. Essayez de nouveau plus tard.
    • 504 Gateway Timeout - Twitter pour les serveurs sont en hausse, mais la demande ne pouvait pas être réparé en raison d'une panne au sein de notre stack. Essayez de nouveau plus tard.
    • Note que j'ai mis en place une assez grande de l'API à l'aide de 200 pour le niveau d'application des erreurs (qui ont ensuite été décrit par le JSON corps de la réponse), et depuis j'ai appris que @MPV est droit. Le supplément de l'analyse de la logique et de flux de code nécessaire pour gérer une de 200 OK HTTP qui représente une application de niveau d'erreur juste complique votre erreur de manipulation. Bâton avec 2XX statut de la réussite et de toutes les erreurs ont une 4XX ou 5XX code d'état. Il rend votre réussite code de manutention plus facile.
    • Mise à jour de l'url pour Twitter Codes: dev.twitter.com/overview/api/response-codes
    InformationsquelleAutor MPV
  2. 1

    Je voudrais envoyer un '400 Bad Request' en-tête arrière en réponse à l'information en json de ce qui s'est passé.
    Puis prendre le cas avec jquerys $.ajaxError() du gestionnaire d'événement et d'analyser le message d'erreur que j'ai obtenu en échange la bonne livraison de la rétroaction à l'utilisateur final.

    Vous pouvez en lire plus sur le ajaxError gestionnaire d'événement ici!

    InformationsquelleAutor Wirde