REST: mappage des erreurs d'application avec les codes d'état HTTP

Question

Est-il être considéré comme une bonne pratique de la réutilisation RFC codes d'État HTTP de ce genre, ou devons-nous faire de nouvelles que la carte exactement à notre erreur spécifique raisons?

Nous sommes en train de concevoir une API de service web autour d'un couple d'applications héritées.

En plus de JSON/XML structures de données dans le Corps de la Réponse, nous avons pour objectif de retourner les Codes d'État HTTP qui ont du sens pour les caches web et les développeurs.

Mais comment allez-vous sur la cartographie des différentes classes d'erreurs sur approprié les codes d'État HTTP? Tout le monde sur l'équipe s'engage sur les points suivants:

GET /package/1234 retourne 404 Non Trouvé si 1234 n'existe pas

GET /package/1234/next_checkpoint retourne 400 Bad Request si "next_checkpoint" et 1234 sont valables pour demander, mais next_checkpont ici n'a pas de sens...

et ainsi de suite... mais, dans certains cas, les choses doivent être plus précis, juste "400" - par exemple:

POSTER /envoi/?for_package=1234 retourne 412 Échec de la Condition préalable si /d'expédition et le paquet de 1234, les deux existent, MAIS 1234 n'est pas prêt pour l'expédition encore.

---

(Edit: les codes d'État HTTP/1.1 et codes de Statut dans WebDAV ext.)

Answer 1

Reposant utilisation de HTTP signifie que vous devez garder à l'API uniforme. Cela signifie que vous ne pouvez pas ajouter le domaine des méthodes spécifiques (ala GET_STOCK_QUOTE), mais cela signifie aussi que vous ne pouvez pas ajouter le domaine des codes d'erreur spécifiques (ala 499 Produit en rupture De Stock).

En fait, le client HTTP codes d'erreur sont une bonne vérification de la conception, car si la conception de votre ressource sémantique correctement, le code d'erreur HTTP signification exprimer correctement les erreurs. Si vous sentez que vous avez besoin d'autres codes d'erreur, votre ressource de conception est probablement faux.

Jan

Answer 2

422 Entité non traitable est un code d'erreur utile pour des scénarios comme celui-ci. Consultez cette question à l' adresse http://stackoverflow.com/questions/2190945/what-http-response-code-for-rest-service-on-put-method-when-domain-rules-invalid/2194786#2194786 pour plus d'informations.

Answer 3

GET /package/1234/next_checkpoint retourne 400 Bad Request si "next_checkpoint" et 1234 sont valables demander mais next_checkpont ici ne fait pas de sens...

C'est la mauvaise façon de penser à propos de cet URI.

Les uri sont opaques, de sorte que l'observation que certaines parties sont "valides" et les autres ne sont pas n'a aucun sens d'un point de vue du client. Vous devez donc "juste" de retourner une erreur 404 pour le client, car la ressource "package/1234/next_checkpoint" n'existe pas.

Answer 4

Vous devez utiliser 4xx les réponses qui correspondent le mieux à votre demande, lorsque le client fait une erreur, mais être prudent de ne pas utiliser ceux qui sont destinés à des en-têtes spécifiques ou des conditions. J'ai tendance à retourner lisible par l'utilisateur message d'état et d'une plaine-version texte de l'erreur, dans le corps de la réponse ou structurée de message d'erreur, en fonction du contexte de l'application.

Mise à jour: Lors de la lecture de la RFC, "procondition a échoué" s'entend, pour le conditionnel en-têtes, comme "if-none-match". Je donnerais un général 400 message à la place.

Answer 5

En fait, vous ne devriez pas faire ça du tout. Votre utilisation de 404 Not Found est correcte, mais 400 Bad Request est utilisée de manière incorrecte. Un 400 Bad Request selon le RFC est utilisé uniquement lorsque le protocole HTTP est mal formé. Dans votre cas, la requête est syntaxiquement correcte, ce n'est qu'un argument inattendu. Vous devez renvoyer un 500 Server Error puis inclure un code d'erreur dans votre résultat REST.