Codes d'état HTTP REST pour une validation échouée ou un doublon non valide

Question

Je suis en train de construire une application avec une API basée sur REST et en sommes venus au point où je suis en précisant les codes d'état pour chaque demande.

Ce code de statut dois-je envoyer les demandes à défaut de validation ou lorsqu'une demande est d'essayer d'ajouter un doublon dans ma base de données?

J'ai regardé à travers http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html mais aucun d'eux ne semble la droite.

Est-il une pratique courante lors de l'envoi des codes d'état?

Answer 1

Pour la validation des entrées de l'échec: 400 Bad Request + votre description facultative. Ce qui est suggéré dans le livre "les Services Web RESTful". Pour le double soumettre: 409 Conflit

---

Mise À Jour Juin 2014

Les spécifications utilisées pour être RFC2616, qui a donné l'utilisation de 400 (Bad Request) plutôt que de justesse

La demande ne peut pas être comprise par le serveur en raison de la malformation de la syntaxe

Donc, il pourrait avoir été soutenu qu'il était inapproprié pour les erreurs de sémantique. Mais pas plus; depuis juin 2014, la norme RFC 7231, qui annule et remplace la précédente RFC2616, donne l'utilisation de 400 (Bad Request) plus large que

le serveur ne peut pas ou ne pas traiter la demande en raison de quelque chose qui est perçu comme une erreur du client

Answer 2

• La validation a échoué: 403 Forbidden ("Le serveur a compris la requête, mais refuse de la satisfaire"). Contrairement à l'opinion populaire, la RFC2616 ne veut pas dire "403 est conçu uniquement pour l'authentification a échoué", mais "403: je sais ce que vous voulez, mais je ne le ferai pas". Cette condition peut ou peut ne pas être due à l'authentification.
• Essayez d'ajouter un doublon: 409 Conflit ("La requête n'a pas pu être terminé en raison d'un conflit avec l'état actuel de la ressource.")

Vous devriez certainement donner une explication plus détaillée dans les en-têtes de réponse et/ou le corps (par exemple, avec un en-tête personnalisé - X-Status-Reason: Validation failed).

Answer 3

Je recommande le code d'état 422, "Entité non traitable" .

Answer 4

200,300, 400, 500 sont tous très générique. Si vous voulez générique, 400 est OK.

422 est utilisée par un nombre croissant d'Api, et est encore utilisé par les Rails de la boîte.

Peu importe le code de statut que vous choisissez pour votre API, quelqu'un qui ne seront pas d'accord. Mais je préfère 422 parce que je pense à '400 + état du texte" comme trop générique. Aussi, vous n'êtes pas de prendre avantage d'un JSON-prêt analyseur; en revanche, 422 avec une réponse JSON est très explicite, et un grand nombre d'informations sur les erreurs peuvent être transmis.

Parlant de la réponse JSON, j'ai tendance à standardiser sur les Rails d'erreur de réponse pour ce cas, qui est:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Ce format est parfait pour la validation d'un formulaire, que je considère le cas le plus complexe à l'appui en termes de rapport d'erreurs richesse. Si votre structure d'erreur est présent, il sera susceptible de répondre à tous vos rapports d'erreur besoins.

Answer 5

Le Code d'état "304 not Modified" serait aussi une réponse acceptable à une double demande. Ceci est similaire à la transformation d'un en-tête de If-None-Match à l'aide d'une balise d'entité.

À mon avis, @Piskvor la réponse est le choix plus évident, à ce que je perçois est le but de la question d'origine, mais j'ai une autre solution qui est également pertinente.

Si vous voulez traiter un double de la demande comme un avertissement ou notification plutôt que comme une erreur, un code d'état de réponse de l' 304 Pas Modifié, et Content-Location - tête identifier les ressources existantes serait tout aussi valable. Lorsque l'intention est simplement de s'assurer que la ressource existe, un double de la demande ne serait pas une erreur mais une confirmation. La demande n'est pas faux, mais c'est tout simplement redondants, et le client peut consulter les ressources existantes.

En d'autres termes, la demande est bonne, mais étant donné que la ressource existe déjà, le serveur n'a pas besoin d'effectuer un traitement supplémentaire.