Codes d'état HTTP REST pour échec de validation ou doublon non valide

Je crée une application avec une API basée sur REST et j'en suis arrivé au point où je spécifie des codes d'état pour chaque demande.

Quel code d'état dois-je envoyer pour les demandes qui n'ont pas été validées ou où une demande essaie d'ajouter un doublon dans ma base de données?

J'ai parcouru http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html mais aucun ne semble correct.

Existe-t-il une pratique courante lors de l'envoi de codes d'état?

En cas d'échec de validation d'entrée: 400 Bad Request + votre description facultative. Ceci est suggéré dans le livre " RESTful Web Services ". Pour double soumission: 409 Conflict

Mise à jour juin 2014

La spécification pertinente était RFC2616 , qui donnait l'utilisation de 400 (Bad Request) de manière assez étroite comme

La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe incorrecte

On aurait donc pu dire que c'était inapproprié pour les erreurs sémantiques. Mais plus maintenant; depuis juin 2014, la norme pertinente RFC 7231 , qui remplace la précédente RFC2616, donne l'utilisation de 400 (Bad Request) plus largement que

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

• Échec de la validation: 403 interdit ("Le serveur a compris la demande, mais refuse de la satisfaire"). Contrairement à l'opinion populaire, la RFC2616 ne dit pas que "403 est uniquement destiné à l'échec de l'authentification", mais "403: je sais ce que vous voulez, mais je ne le ferai pas". Cette condition peut ou non être due à l'authentification.
• Tentative d'ajout d'un doublon: 409 Conflit ("La demande n'a pas pu être terminée 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 et / ou le corps de la réponse (par exemple avec un en-tête personnalisé - X-Status-Reason: Validation failed).

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

11.2. 422 Entité non traitable

Le code d'état 422 (entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 (type de support non pris en charge) est inapproprié) et la syntaxe de l'entité de demande est correcte (donc 400 (mauvaise demande) ) le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes) mais sémantiquement erronées.

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

422 est utilisé par un nombre croissant d'API, et est même utilisé par Rails prêt à l'emploi.

Quel que soit le code d'état que vous choisissez pour votre API, quelqu'un sera en désaccord. Mais je préfère 422 parce que je pense que '400 + statut du texte' est trop générique. De plus, vous ne profitez pas d'un analyseur prêt pour JSON; en revanche, un 422 avec une réponse JSON est très explicite, et beaucoup d'informations d'erreur peuvent être transmises.

En parlant de réponse JSON, j'ai tendance à standardiser la réponse d'erreur Rails 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 de formulaire, que je considère comme le cas le plus complexe à prendre en charge en termes de «richesse de rapport d'erreurs». Si votre structure d'erreurs est la suivante, elle gérera probablement tous vos besoins de rapport d'erreurs.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... beaucoup de réponses essayant de deviner, argumenter et standardiser quel est le meilleur code retour pour une requête HTTP réussie mais un appel REST ayant échoué .

C'est mal de mélanger les codes d'état HTTP et les codes d'état REST.

Cependant, j'ai vu de nombreuses implémentations les mélanger, et de nombreux développeurs peuvent ne pas être d'accord avec moi.

Les codes de retour HTTP sont liés à HTTP Requestlui - même. Un appel REST est effectué à l'aide d'une demande de protocole de transfert hypertexte et il fonctionne à un niveau inférieur à la méthode REST invoquée elle-même. REST est un concept / approche, et sa sortie est un résultat métier / logique , tandis que le code de résultat HTTP est un transport .

Par exemple, retourner "404 Not found" lorsque vous appelez / users / est confus, car cela peut signifier:

• L'URI est incorrect (HTTP)
• Aucun utilisateur trouvé (REST)

"403 Interdit / Accès refusé" peut signifier:

• Autorisation spéciale nécessaire. Les navigateurs peuvent le gérer en demandant à l'utilisateur / mot de passe. (HTTP)
• Autorisations d'accès incorrectes configurées sur le serveur. (HTTP)
• Vous devez être authentifié (REST)

Et la liste peut continuer avec '500 Server error "(une erreur HTTP Apache / Nginx lancée ou une erreur de contrainte métier dans REST) ​​ou d'autres erreurs HTTP, etc.

À partir du code, il est difficile de comprendre quelle était la raison de l'échec, un échec HTTP (transport) ou un échec REST (logique).

Si la requête HTTP a été exécutée physiquement avec succès, elle doit toujours renvoyer 200 codes, quel que soit le ou les enregistrements trouvés ou non. Parce que la ressource URI est trouvée et a été gérée par le serveur HTTP. Oui, il peut renvoyer un ensemble vide. Est-il possible de recevoir une page Web vide avec 200 comme résultat HTTP, non?

Au lieu de cela, vous pouvez retourner 200 codes HTTP avec quelques options:

• objet "erreur" dans le résultat JSON en cas de problème
• Tableau / objet JSON vide si aucun enregistrement trouvé
• Un indicateur de résultat / succès booléen en combinaison avec les options précédentes pour une meilleure manipulation.

De plus, certains fournisseurs d'accès Internet peuvent intercepter vos demandes et vous renvoyer un code HTTP 404. Cela ne signifie pas que vos données ne sont pas trouvées, mais c'est quelque chose de mal au niveau du transport.

De Wiki :

En juillet 2004, le fournisseur britannique de télécommunications BT Group a déployé le système de blocage de contenu Cleanfeed, qui renvoie une erreur 404 à toute demande de contenu identifié comme potentiellement illégal par Internet Watch Foundation. D'autres FAI renvoient une erreur HTTP 403 "interdite" dans les mêmes circonstances. La pratique consistant à utiliser de fausses erreurs 404 comme moyen de dissimuler la censure a également été signalée en Thaïlande et en Tunisie. En Tunisie, où la censure était sévère avant la révolution de 2011, les gens ont pris conscience de la nature des fausses erreurs 404 et ont créé un personnage imaginaire nommé "Ammar 404" qui représente "la censure invisible".

Pourquoi ne pas simplement répondre avec quelque chose comme ça?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google renvoie toujours 200 comme code d'état dans son API de géocodage, même si la demande échoue logiquement: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook renvoie toujours 200 pour les demandes HTTP réussies, même si la demande REST échoue: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

C'est simple, les codes d'état HTTP sont pour les requêtes HTTP. L'API REST vous appartient, définissez vos codes d'état.

Un doublon dans la base de données devrait être a 409 CONFLICT.

Je recommande d'utiliser 422 UNPROCESSABLE ENTITYpour les erreurs de validation.

Je donne une explication plus longue des codes 4xx ici .

Le code de statut 304 non modifié donnerait également une réponse acceptable à une demande en double. Cela revient à traiter un en-tête à l' If-None-Matchaide d'une balise d'entité.

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

Si vous souhaitez traiter une demande en double comme un avertissement ou une notification plutôt que comme une erreur, un code d'état de réponse 304Non modifié etContent-Location tête identifiant la ressource existante seraient tout aussi valides. Lorsque l'intention est simplement de garantir l'existence d'une ressource, une demande en double ne serait pas une erreur mais une confirmation. La demande n'est pas fausse, mais est simplement redondante et le client peut se référer à la ressource existante.

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

L'adaptateur ActiveRecord d'Ember-Data s'attend 422 UNPROCESSABLE ENTITYà être renvoyé du serveur. Donc, si votre client est écrit dans Ember.js, vous devez utiliser 422. Seulement alors, DS.Errors sera rempli avec des erreurs renvoyées. Vous pouvez bien sûr remplacer 422 par n'importe quel autre code dans votre adaptateur.

406 - Inacceptable

Ce qui signifie que cette réponse est envoyée lorsque le serveur Web, après avoir effectué une négociation de contenu pilotée par le serveur, ne trouve aucun contenu conforme aux critères donnés par l'agent utilisateur.