Wake Up REST à la Cantine
30 septembre 2008
J’ai eu la chance de participer jeudi matin (25/09) à une nouvelle initiative de Didier Girard (au fait, merci Didier), grand animateur de la communauté des architectes. Un « Wake Up » : ambiance conviviale autour d’un café à la Cantine (un peu tôt pour la bière tout de même !) pour une rencontre qui se voulait un brin polémique. L’idée était de nous faire réagir à l’arrivée de REST dans les architectures Web.
Didier nous présente REST comme un retour aux sources : finalement le web comme outil de publication documentaire à fait ses preuves, pourquoi ne pas voir une application comme un fournisseur de ressources (vues logiques sur les données) mises à disposition par les applications. Chaque ressource peut-être lue (GET), mise à jour (POST), créée (PUT) ou supprimée (DELETE) via une opération HTTP standard. Un des intérêts, faciliter la mise à disposition des données du SI (agrégée à la demande via des portails) et susciter de nouveaux usages.
Retour de balancier : la SOA voyait l’application comme fournisseur de services, les données n’étant que les valeurs de sortie des-dits service, REST nous propose une vision duale de la SOA, où les traitements sont implicites (une donnée est dans un état qui est gouverné par la dernière requête qui y a accédé).
Comme je l’ai dit lors de notre discussion jeudi, j’ai encore du mal à voir la valeur ajoutée, ou plutôt, j’ai l’impression que l’architecture REST, comme la SOA, est réductrice : les applications de gestion (celles sur lesquelles je travaille) sont plutôt conçues par rapport aux processus qu’elles automatisent et donc, centrées sur des activités métier (qui correspondent aux cas d’utilisation de l’application). Seules exceptions, les Référentiels, responsables de garantir la cohérence des données de références du SI ne fournissent souvent que des services CRUD (justement ceux cités plus haut). REST serait l’architecture adaptée à la mise à disposition en architecture web des Référentiels du SI ?
Je pense surtout qu’on tourne en rond ! Au « commencement » on publiait des documents sans état (web 1.0). On s’est rendu compte que pour faire des « vraies » applications, on avait besoin de publier des services (avènement de la SOA). On trouve ça trop compliqué (à juste titre) et on revient à la publication des données.
En fait quel est le besoin ? C’est la notion de « formulaire » au sens large : des données affichées + des traitements associés (les boutons). Suivant le cas, l’intérêt de l’utilisateur est plutôt centré sur les données ou sur les traitements.
Dans le cas général, cette chose étrange qui réunit des données et des traitements, on pourrait par exemple l’appeler un « objet » et se demander comment le publier sur le web…
Vivement la prochaine fois pour un Tribunal du SI ;-)