Ce billet fait suite à un échange avec Xavier Fournier Morel de SQLI Suisse.
Google a pendant longtemps proposé une API SOAP permettant d’intégrer ses fonctions de recherche au sein d’une application par l’invocation d’un Web Service.
Aujourd’hui, seule une API AJAX est disponible : Google privilégie l’approche mashup à une approche SOA (cf. ce billet).
Cette approche, pertinente dans le cas de Google Maps, l’est moins dans le cas de la recherche : en effet, elle impose l’intégration de l’IHM (interface homme machine) de Google au sein de la page qui fait appel au service, ce qui est assez intrusif.
De plus la recherche n’est plus possible depuis un composant métier, elle ne peut se faire que depuis une IHM, ce qui limite beaucoup les possibilités. Du point de vue d’un architecte, c’est une grande régression.
Enfin, si la disparition du contrat WSDL ne pose pas de problème aux intégrateurs HTML, elle fait perdre du temps aux développeurs chevronnés qui utilisent des environnements de développement capables d’introspection WSDL.
Cet exemple montre les limites du modèle REST : privilégier la simplicité d’intégration se fait parfois aux dépends de la flexibilité et de l’évolutivité des services.
Les acteurs du monde des services en ligne (SaaS) ont fait cette analyse. Ils sont aujourd’hui en train de réinventer WSDL (cf. cet article d’un architecte de Google). Les candidats à la description d’un service REST sont : WRDL, NRDL, SMEX-D, Resedel, RSWS, WDL, WADL,…
Je me demande si tout ça va dans la bonne direction
Qu’en pensez-vous?