APPLICATIONS

De part ce recours "furtif" aux protocoles standards, Soap ne permet de bénéficier d'aucun des mécanismes mis au point au fil des années pour optimiser la conversation web : les proxies, les caches et même les firewalls ou les listes de contrôles d'accès sont complètement court-circuités par les échanges Soap. Les défauts de conception de Soap sont tellement évidents que la version la plus récente de ce protocole (la 1.2) permet enfin d'avoir recours à la fonction HTTP Get à la place du POST qui était incontournable jusque-là. Mais si Soap n'est qu'un sous-Corba mal revu et à peine corrigé, par quoi le remplacer ? Par XML-RPC ? Certainement pas. Cette autre création de Dave Winer présente le même défaut fondamental que Soap : c'est un appel de procédure qui n'utilise HTTP qu'en mode tunnel.

Un mode de compréhension du web

Il existe une alternative mais elle est encore peu connue, il s'agit de REST, une architecture de services web. C'est l'acronyme de REpresentational State Transfer. Elaboré en l'an 2000 par Roy Fielding, l'un des créateurs du protocole HTTP, du serveur Apache HTTPd et d'autres travaux fondamentaux, REST est à l'origine une tentative de décrire les principes de l'architecture du web. Il faut bien comprendre que REST n'est pas en soi un standard : il n'existe pas de spécification du W3C pour la décrire. Il s'agit plutôt d'un style d'architecture, d'un "mode de compréhension du web" sur lequel le développeur construit ses services (web). La bonne surprise avec REST c'est que vous n'avez besoin de rien d'autre que ce que vous avez déjà en matière de standard : HTTP, les URI et XML.

Le modèle qu'Amazon.com a retenu pour ses web services

En effet, un service web "RESTful" se distingue largement d'un service Soap ou XML-RPC en cela qu'il repose uniquement sur l'utilisation d'HTTP, des URIs et d'XML là où les deux autres protocoles se compliquent la tâche en utilisant des API RPC (Remote Procedure Call, appel de procédure distante). Soap et XML-RPC ne suivent pas la spécification HTTP, car ils ajoutent une nouvelle couche d'abstraction par-dessus le protocole, plutôt que de l'utiliser tel qu'il a été conçu. REST part du principe selon lequel HTTP suffit largement à l'ensemble des besoins d'un service web, pour peu que l'on utilise l'ensemble des méthodes de ce protocole : GET, POST, mais aussi PUT, Delete, Connect... Pour résumer, là où Soap et XML-RPC se basent sur des méthodes, REST se base sur les ressources existantes.

Bien que peu connue, REST n'est pas une niche exotique vénérée seulement de quelques rares initiés. Il faut savoir que c'est le modèle qu'Amazon.com a retenu pour ses web services. La mauvaise surprise, c'est que REST n'est soutenue par aucun des grands fournisseurs du marché qui tous préfèrent la complexité de Soap et peuvent ainsi discuter entres eux sans fin sur ses nécessaires évolutions... Ceux qui vous disent qu'on ne peut pas faire de véritables web services avec REST sont les mêmes qui vous disaient, il y a quelques années, qu'on ne pouvait pas réaliser de véritables applications transactionnelles avec le web...

Grâce à REST, c'est toute une nouvelle classe d'applications qui va voir le jour afin de transformer et de compléter les solutions de CRM avec les logiciels de gestion du capital relationnel.

Lire la première partie de l'article