Code retour erreur métier service REST

[oli]

Bonjour à tous,

J'aurais aimé avoir votre avis sur le code http à utiliser pour retourner au client une erreur métier pour un service REST.

Exemple d'erreur : "Code TVA non applicable" ou "Erreur de stock" ou encore "Fournisseur bloqué", etc... bref, des erreurs purement métier non liées à des droits d'accès ou ressources manquantes.

Le code 500 ne me paraît pas approprié (plutôt erreur système), le 200 avec un message d'erreur pourquoi pas mais généralement on l'utilise quand tout c'est bien passé ...

Peut être le 403 ? des avis ?

Merci d'avance et @+

[Pierre-Yves Ricau]

J'opterai pour un http status de type 4XX (client error), avec en body une description json de l'erreur. Il faut absolument éviter les 200 en cas d'erreur, c'est une mauvaise pratique.

Cf http://restpatterns.org/HTTP_Status_Codes

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/tVotxp_wWbEJ.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Pierre-Yves Ricau

http://www.piwai.info

[Baptiste MATHUS]

+1 sur le fait de ne surtout pas utiliser le code 200 pour les erreurs.

Par exemple, si tu dois faire ensuite du test de perf, tu t'économiseras du travail si cela a été bien fait. (Et tu pourras taper plus fort sur l'appli avec les mêmes ressources client, puisque ton CPU n'aura pas à s'occuper de regarder le contenu du retour de la requête à grands coups de regex).

Baptiste

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Clement Escoffier]

Bonjour

Voila les codes que j'utilise dans mes services REST:

- 404 si la resource n'est pas la. Certains puristes vont distinguer le 404 (pas la) et 410 (plus la), mais bon, pour moi ça change pas grand chose.

- 403 si la resource n'est pas accessible (authentication…).

- 409 si l'etat de la ressource ne permet pas de faire la modif que tu veux

Pour tout le reste: 400 - Bad Request

Toutes ces erreurs sont accompagnés d'un objet JSON (pouvant contenir un code interne d'ailleurs) ou d'une page HTML (suivant le ACCEPT de la requête), décrivant l'erreur, et si possible une stacktrace. 

Je réserve les 50x pour les erreurs systèmes 'inattendues' (non métier). 

20x est utilisé seulement en cas de succès système et métier. Ca permet aussi de simplifier le code JavaScript de ton client. Par exemple, avec jquery le callback 'success' est appelé sur tous les 20x, et 'error' pour tous les autres (40x et 50x (et certains 30x aussi)). Malheureusement, le traitement dans le callback error est plus délicat car le retour utilisateur est différent entre un 40x (erreur métier) et un 50x (appel le support immédiatement…).

 Clement

[Grégory Bougeard]

https://github.com/joho/7XX-rfc

what else?

[Bruno Durand]

Bonjour,

Je suis un peu surpris des réponses, ça me gène de gérer des exceptions fonctionnelles avec des exceptions de la couche de transport. J'aurais plutôt tendance à penser que des exceptions fonctionnelles doivent renvoyer un 200 (le transport est ok), et gérée par la couche application, car c'est un cas d'utilisation normal de l'API, par exemple le gars a dépasser un plafond autorisé. Maintenant, je me fourvoie peut être, j'aimerai connaitre vos motivations pour utiliser ces exceptions, les avantages et inconvénients.

Merci,

Z.

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/Syvrl6GNslAJ.

[Charles Sabourdin]

2012/6/8 Grégory Bougeard <gbou...@gmail.com>

https://github.com/joho/7XX-rfc

what else?

418 

[Thibaud Vibes]

Le 08/06/2012 10:02, Bruno Durand a écrit :

Bonjour,

Je suis un peu surpris des réponses, ça me gène de gérer des exceptions fonctionnelles avec des exceptions de la couche de transport. J'aurais plutôt tendance à penser que des exceptions fonctionnelles doivent renvoyer un 200 (le transport est ok), et gérée par la couche application, car c'est un cas d'utilisation normal de l'API, par exemple le gars a dépasser un plafond autorisé. Maintenant, je me fourvoie peut être, j'aimerai connaitre vos motivations pour utiliser ces exceptions, les avantages et inconvénients.

Merci,

HTTP ne prévoit pas des erreurs de la couche transport: Erreur 500 n'a rien à voir avec le transport.
HTTP n'est pas du transport selon moi (TCP oui). HTTP est un protocole applicatif donc pourquoi ne pas réutiliser ces erreurs?

Pour revenir aux exemples ci-dessous, voici des suggestions (qui ne valent pas plus de 2 centimes) :
"Code TVA non applicable" => 400 (Bad Request)
"Erreur de stock" => ça dépend de ce qu'on entend par erreur. 503 si y a eu une erreur en lisant le stock, sinon pourquoi pas une 404


Sinon pourquoi ne pas utiliser tes propres codes (en 6XX par exemple)? J'ai un souvenir que c'est ce que pouvait renvoyer l'api google de geocoding (je ne sais pas si c'est encore comme ça)?
Est-ce que c'est mauvaise pratique?

[Patrice Trognon]

Le 8 juin 2012 à 10:19, Thibaud Vibes a écrit :

Le 08/06/2012 10:02, Bruno Durand a écrit :

Bonjour,

Je suis un peu surpris des réponses, ça me gène de gérer des exceptions fonctionnelles avec des exceptions de la couche de transport. J'aurais plutôt tendance à penser que des exceptions fonctionnelles doivent renvoyer un 200 (le transport est ok), et gérée par la couche application, car c'est un cas d'utilisation normal de l'API, par exemple le gars a dépasser un plafond autorisé. Maintenant, je me fourvoie peut être, j'aimerai connaitre vos motivations pour utiliser ces exceptions, les avantages et inconvénients.

Merci,

HTTP ne prévoit pas des erreurs de la couche transport: Erreur 500 n'a rien à voir avec le transport.
HTTP n'est pas du transport selon moi (TCP oui). HTTP est un protocole applicatif donc pourquoi ne pas réutiliser ces erreurs?

Pour revenir aux exemples ci-dessous, voici des suggestions (qui ne valent pas plus de 2 centimes) :
"Code TVA non applicable" => 400 (Bad Request)

voila en code de retour j'utilise le BadRequest, et dans le body je renvoie un code d'erreur applicatif que je vais

traiter par parsing dans mon code, éventuellement ce code d'erreur peut être suivi d'un message.

et franchement je ne me prend pas plus la tête que ça.

Pat

[Bruno Durand]

oups je voulais dire du protocole (et non la couche de transport désolé)

[Samuel Le Berrigaud]

Hello,

je suggère le livre Restful Web Services [1] pour mieux comprendre les codes de retour et REST en général. C'est une bonne référence.

Pour ce qui est des code de retour, 200 ne signifient pas que le transport est ok mais bien que l'ensemble de la requête s'est bien passé. En effet, quand on reçoit un 404, par exemple, le transport est ok, simplement la page (resource) demandée n'a pas été trouvée côté serveur.

[1] http://www.amazon.fr/Restful-Web-Services-Leonard-Richardson/dp/0596529260

SaM

[Julien Vermillard]

Suffit de regarder cette cheat sheet :
http://boingboing.net/2011/12/14/http-status-cats-by-girliemac.html

Désolé ..

Julien

2012/6/8 Samuel Le Berrigaud <samu...@gmail.com>:

[Emmanuel Lécharny]

Le 6/8/12 12:47 PM, Julien Vermillard a écrit :

> Suffit de regarder cette cheat sheet :
> http://boingboing.net/2011/12/14/http-status-cats-by-girliemac.html
>
> Désolé ..

Excellent les Cat100Cats !


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[oli]

Merci pour vos réponses,

Comme suggéré par Thibaud, je vais opter pour l'erreur 400 : Bad request qui me paraît la plus opportune pour les erreurs fonctionnelles

[Frédéric Camblor]

Bonjour tous !

Je profite rapidement de ce thread pour vous demander la même chose sur une erreur de validation (les données envoyées ne sont pas cohérentes : par exemple la date de début est supérieure à la date de fin)

[pub]Dans le dernier article de mon blog[/pub], j'optais pour le 412 (precondition failed), mais il s'agit là d'un petit détournement de la spec initiale.

Une autre option étant de retourner une 4xx (comme suggéré plus tôt), cela pose le problème de la foultitude des erreurs possibles retournée par une appli (le projet 7xx l'illustre bien ;)), il faudrait du coup mettre en place un lexique de types JSON assez faramineux pour transmettre une structure adéquate au client en fonction du corner case obtenu coté serveur.

C'est pour ça qu'avoir un code HTTP dédié à ce type de problématique (qui possède une structure JSON bien spécifique, avec l'ensemble des erreurs de validation par champs envoyés) me plaît plus que le "one 4xx HTTP code to rule them all".

Votre avis m'intéresse sur la question :-)

Frédéric Camblor  

Bordeaux JUG Board member

Jenkins community member & plugin commiter

2012/6/14 oli <omei...@gmail.com>

Merci pour vos réponses,

Comme suggéré par Thibaud, je vais opter pour l'erreur 400 : Bad request qui me paraît la plus opportune pour les erreurs fonctionnelles

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/b3HkXuRQujIJ.