Qu'est ce qu'un code d'état HTTP approprié pour revenir par une API REST pour un service de validation de l'échec?

Question

Je suis actuellement de retour 401 non autorisé chaque fois que je rencontre un échec de validation dans mon Django/Piston API REST de l'application. Ayant eu un coup d'oeil au Code de Statut HTTP de Registre Je ne suis pas convaincu que c'est un code approprié pour un échec de validation, ce n'y'all recommander?

• 400 Bad Request
• 401 non autorisé
• 403 Forbidden
• 405 Method Not Allowed
• 406 Not Acceptable
• 412 Échec De La Condition Préalable
• 417 Échec De L'Attente
• 422 Unprocessable Entité
• 424 Échec De La Dépendance

Mise à jour: "échec de Validation" ci-dessus, une demande de données au niveau de la validation de l'échec, par exemple, mal spécifié datetime, de pseudo, adresse email, etc.

Answer 1

Si "l'échec de validation" signifie qu'il existe une erreur du client dans la demande, à l'utilisation de HTTP 400 (Bad Request). Par exemple, si l'URI est censé avoir un ISO-8601 date et vous trouvez que c'est dans le mauvais format ou se réfère à février 31, alors vous seriez de retour HTTP de 400. Idem si vous vous attendez XML bien formé dans un corps d'entité et ne parvient pas à analyser.

Richardson et de Rubis Services Web RESTful contient un très utile de l'annexe sur l'utilisation des différents codes de réponse HTTP. Ils disent:

400 ("Bad Request")
Importance: Haute.
C'est le générique du côté client, le statut de l'erreur, en l'absence d'autres 4xx code d'erreur approprié. Il est couramment utilisé lorsque le client soumet une représentation avec un METTRE ou POST, et la représentation est dans le bon format, mais il ne fait pas a aucun sens. (p. 381)

et:

401 ("non autorisé")
Importance: Haute.
Le client a tenté d'opérer une ressource protégée sans fournir la bonne authentification des informations d'identification. Il peut avoir fourni les informations d'identification de mal, ou pas du tout. Les informations d'identification peut être un nom d'utilisateur et le mot de passe, une clé API, ou une authentification jeton-quel que soit le service en question est attend. Il est commun pour un client de faire une demande pour une URI et d'accepter un 401 juste pour qu'il sache quel type d'informations d'identification pour envoyer et dans quel format. [...]

Answer 2

De la RFC 4918 (et aussi documenté à l' http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml):

Les 422 (Unprocessable Entité) code du statut signifie que le serveur comprend le type de contenu de la demande de l'entité (d'où une 415(Unsupported Media Type) code d'état est inapproprié), et le la syntaxe de l'entité de la requête est correcte (donc un 400 (Bad Request) le code d'état est inapproprié), mais a été incapable de traiter le contenu de l' les instructions. Par exemple, cette condition d'erreur peut se produire si un XML du corps de la requête contient bien formé (c'est à dire, syntaxiquement correctes), mais sémantiquement erronée, instructions XML.

Answer 3

Je dirais que techniquement il ne pourrait pas être un HTTP échec, puisque la ressource est (sans doute) valablement spécifié, l'utilisateur a été authentifié, et il n'y avait pas de problèmes d'exploitation (toutefois, même les spec ne comprennent certains des codes réservés comme 402 Paiement Requis qui ne sont pas, à strictement parler, HTTP, soit, mais il serait peut-être souhaitable qu'au niveau du protocole, de sorte que n'importe quel appareil peut reconnaître l'état).

Si c'est effectivement le cas, je voudrais ajouter un champ d'état à la réponse à des erreurs d'application, comme

<statut><code>4</code><message>plage de Date n'est pas valide</message></status>

Answer 4

Il y a un peu plus d'informations sur la sémantique de ces erreurs dans la RFC 2616, documents HTTP 1.1.

Personnellement, je serais probablement utiliser 400 Bad Request, mais c'est juste mon opinion personnelle, sans preuves factuelles.

Answer 5

Que voulez-vous dire exactement par "échec de validation"? De quoi êtes-vous de la validation? Voulez-vous parler de quelque chose comme une erreur de syntaxe (par exemple, XML mal formé)?

Si c'est le cas, je dirais 400 Bad Request est probablement la bonne chose, mais sans savoir ce que c'est que vous êtes de "valider", il est impossible de dire.