Maintenir la compatibilité ascendante des webservices




 

Je vous propose de vous montrer pourquoi la compatibilité ascendante des webservices est nécessaire.

 

Pourquoi les web services évoluent ?

Dans des SI à architecture complexe, il est parfois préconisé de mutualiser certains besoins métier. Cette mutualisation se fait par le biais des web services.

Les spécifications d’un webservice sont guidés par les besoins des applicatifs utilisateurs : un applicatif qui évolue, va parfois nécessiter qu’un webservice évolue.

 

Pourquoi maintenir une compatibilité ascendante ?

Le soucis est que les applicatifs utilisateurs n’évoluent pas tous au même rythme. De ce fait, un web service qui évolue doit rester compatible avec ses précédentes versions pour ne pas mettre en péril des applicatifs à cycles d’évolution plus lents.

 

Comment maintenir une compatibilité ascendante ?

Deux solutions s’offrent à vous :
– la première solution consiste à être vigilant sur les entrées et sorties du webservice;
– la seconde solution consiste à versionner le webservice.

 

Etre vigilant sur les entrées et les sorties du webservice

Cette solution vous oblige :
– à garder une sortie :
* au mieux, qui ne varie pas au fil des versions,
* au minimum conserve les éléments et le format de la sortie précédente à laquelle s’ajouterait de nouveaux éléments;
– à garder en entrée les paramètres existants, si besoin ajouter de nouveaux paramètres, mais surtout à ne rendre aucun paramètre obligatoire;
– à gérer un message d’erreur en l’absence de paramètres.

Cette solution a ses limites dues au format utilisé pour la sortie (xml, json, …) et pose des contraintes fortes aux développeurs.
 

Versionner un webservice

Cette solution consiste à intégrer un numéro de version à votre webservice. Ainsi, il est possible de faire évoluer l’entrée et la sortie indépendamment des versions précédentes du webservice. Toutefois, il est une bonne pratique de garder un minimum de cohérence entre les versions d’un même webservice.

Des applicatifs distincts utiliseront des versions différentes d’un même webservice.

Cette solution a l’avantage de ne poser aucune contrainte aux développeurs, hormis celle de la cohérence entre versions.
Par contre, elle nécessite de garder en production des versions différentes d’un même webservice.

 

Conclusion

Bien que ma préférence aille à la seconde solution, aucune des deux n’est parfaite. Dans un prochain article, je vous montrerai comment mettre en œuvre cette compatibilité ascendante. N’hésitez pas à poser vos questions par le biais des commentaires.

 

Posté dans javaTaggé client webservice, code first, contract first, CXF, cxf maven dependency, implementation first, java, webservice, webservice compatibilité, webservice contract first  |  Laisser un commentaire

Répondre

*