REST ou SOAP pour les web services ?
Architectures orientées services SOA

L’introduction de la spécification Web Method dans SOAP 1.2 permet à SOAP de se conformer au style REST. Cette faiblesse de SOAP ayant été comblée, le débat sur la différence entre ces deux approches est donc devenu en partie sans objet.

Dans les deux cas, les données sont échangées sous la forme de XML sur HTTP. Il n’y a donc pas, de ce point de vue, de différence en terme de performance ou de fiabilité contrairement aux affirmations de certains vendeurs SOAP. Le fait d’ajouter une enveloppe SOAP autour des données est neutre. Qui d’ailleurs se sert de cette enveloppe ?

La plupart des grands sites qui offrent des services web aux développeurs comme Amazon ou eBay offrent simultanément les deux types d’interfaces. L’écrasante majorité (plus de 85 %) des centaines de milliers de développeurs choisissent REST comme interface, essentiellement pour des raisons de simplicité. La barre adresse d’un navigateur suffit pour écrire et tester une requête REST alors que SOAP impose l’emploi d’un langage de programmation et de l’infrastructure correspondante. Ces sites ont par ailleurs unifié les données manipulées par les services SOAP ou REST, ce qui réduit encore l’écart qui aurait pu exister.

La plus grande différence entre les deux styles est le nom de la ressource. Dans le style REST, le nom de la ressource est dans l’URI (figure 6) alors que dans le style SOAP, tous les messages sont généralement envoyés vers un point d’entrée unique (figure 7). Le nom de la fonction à effectuer est caché à l’intérieur de l’enveloppe. Cette manière de faire peut présenter des avantages dans certains cas, en particulier quand certaines parties du message doivent rester confidentielles. En revanche, dans la majorité des cas, c’est plutôt un inconvénient. Le point d’entrée unique entraîne un couplage fort et un goulot d’étranglement qui complique la gestion des priorités et des performances. Le mécanisme simple décrit précédemment 3.6...