Trop souvent le code de réponse HTTP retourné par un service en cas d’erreur ne vaut pas ce qu’il devrait valoir.
C’est pourtant un moyen simple et léger d’indiquer au client le type d’erreur retourné.
 

 
N’avez-vous jamais rencontré un service qui retourne les erreurs avec un code de réponse HTTP 200 OK … ?
Ne serait-ce pas plus compréhensible de renvoyer le bon code de réponse HTTP, celui qui indique clairement ce qu’il s’est passé ?
Voici un lien vers la section 10 de la RFC2616 qui recense tous les codes de réponses HTTP :
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Introduction

Même si la plupart du temps, en cas d’erreur, il s’agira du code de réponse HTTP 500 Internal Server Error, ce dernier a au moins le mérite d’être un code d’erreur (ce qui n’est pas le cas du code 200).
Mais avec la montée en force du style d’architecture REST depuis plusieurs années, les verbs et codes de réponses HTTP ont repris de l’importance et on fera alors attention à affiner les valeurs, à être plus précis.
En effet, en REST, on parle de ressource.
Ci-dessous l’exemple d’une URL permettant de retourner la représentation de la ressource de type Personne qui a comme identifiant « 1234 » :
http://api.entreprise.fr/api/v1/personnes/1234
Dans cet exemple, si la personne recherchée n’existe pas, plutôt que de retourner un message d’erreur accompagné d’un code de réponse HTTP 500 Internal Server Error, on préférera le code de réponse HTTP 404 Not Found qui a justement cette signification. Le code de réponse HTTP seul suffit donc au client pour comprendre que la ressource est introuvable.

Intégration

Maintenant que l’on a rappelé l’importance d’utiliser les bons codes de réponses HTTP, on peut considérer que les codes renvoyés par les services de notre SI sont corrects.
Si l’on décide d’exposer un de ces services dans l’OSB, il faut bien évidemment que le code de réponse HTTP retourné par l’OSB soit celui qui est retourné par le service. Autrement, il y aurait une perte d’information dont l’OSB serait responsable.
Je précise ce point car dans l’implémentation d’un service OSB, il y a généralement une gestion d’erreur, un Error Handler qui contient une suite d’actions à exécuter en cas d’erreur (report, alertes, etc) pour maîtriser l’erreur. Et généralement, cela se termine par une l’activité Reply.
Voici un extrait d’un OSB Pipeline Template qui contient un Error Handler qui se termine par l’activité Reply (2) :

Le problème de cette activité est qu’il n’y a que deux options possibles, With Failure ou With Success :
With Failure renverra immédiatement la réponse au client avec le code de réponse HTTP 500 Internal Server Error
With Success renverra immédiatement la réponse au client avec le code de réponse HTTP 200 OK
Dans notre cas de gestion d’erreur, on choisira donc l’option With Failure. Mais en procédant ainsi, si le service applicatif retourne un code de réponse HTTP 404 Not Found, l’information sera perdue en passant par l’OSB car le Error Handler interviendra et renverra HTTP 500 Internal Server Error à cause du Reply With Failure.
C’est l’activité Insert (1) qui permet d’éviter ce problème et de faire suivre le code de réponse HTTP 404 Not Found retourné par le service applicatif.
Voici ce qu’elle contient :

Comme vous le comprenez, on insère dans le bloc response de la variable $inbound l’élément http-response-code du bloc response de la variable $outbound.
En d’autres termes, on demande à l’OSB de faire suivre à son client, le code de réponse HTTP qu’il a lui-même reçu du service applicatif, car ce n’est pas fait de base…

Conclusion

Avec une simple action, placée au bon endroit, on peut s’assurer que l’OSB fera suivre le code de réponse HTTP qu’il a lui-même reçu, sans le modifier et garantir ainsi la maîtrise du code de retour HTTP.
Reste ensuite aux services applicatifs de jouer le jeu, en choisissant le code de réponse HTTP qui correspond le plus possible à la réponse qui est renvoyée.
Mais j’ai déjà assez insisté là-dessus 🙂