Hier soir, j'ai eu de nouveau le plaisir d'expliquer à un proche la différence entre REST et SOAP autour d'une bière. Ça devient une habitude, ces explications et les bières qui les accompagnent.

Je répond à ces sollicitations car je suis familier de ces deux concepts : je suis passionné par REST et je travaille dans une société de services qui produit du SOAP.

Ah ! Je sens que j'ai commencé à titiller la curiosité de certains lecteurs qui se demandent ce que peuvent bien signifier ces deux termes. Et bien, je vais vous les expliquer, mais à ma façon : avec des bières.

Première pinte : Web Services, ROA et SOA

Que dites vous d'une Tripel Karmeliet pour commencer ?

On évoque les termes REST et SOAP quand on parle de Web Services. Les Web Services permettent la consultation et la manipulation à distance d'informations (ce qui est loin d'être un exploit en soi) en utilisant les technologies du Web (et c'est là leur atout car ces technologies sont bien maîtrisées, fiables et universellement déployées).

Une correction avant la suite : malgré l'usage, il n'est pas judicieux de comparer directement REST et SOAP. Nous verrons pourquoi plus tard et nous allons désormais comparer les deux principales architectures de Web Services : ROA (Architecture Orientée Ressources) et SOA (Architecture Orientée Services).

Leur opposition peut s'exprimer aisément :

• Dans un Web Service ROA, on utilise peu de méthodes (les méthodes HTTP) pour manipuler de nombreuses ressources (donc de nombreux URL).
• Dans un Web Service SOA, on utilise de nombreuses méthodes pour manipuler une unique ressource (donc un seul URL, appelé le "endpoint", le point d'accès).

À ce stade, je pense que les moins technophiles de mes lecteurs ont déjà décroché. C'est à cause de la terminologie car je vous assure que les principes décrits sont familiers, puisqu'on les retrouve dans la langue française. Ne vous a-t-on jamais reproché au cours de vos jeunes années d'utiliser le verbe "faire" à outrance ? Ou de dire "truc" à la place du terme exact ?

Dans le Web, on donne des ordres, à l'impératif, dont les méthodes sont les verbes et les ressources les noms. Je reformule l'opposition entre ROA et SOA avec des mots moins intimidants :

• Dans un Web Service ROA, on s'exprime en utilisant un petit nombre de verbes et un grand nombre de noms.
  De la même manière qu'en français, on peut tout dire ou presque avec seulement les verbes "faire", "être" et "avoir" à condition que la faible expressivité du verbe soit compensée par celle du complément.
  Par exemple : "Fais la cuisine" et "fais la réparation".
• Dans un Web Service SOA, on s'exprime en utilisant un grand nombre de verbes et un seul nom.
  De même qu'en français, on peut être compris malgré l'usage de "truc", "bidule" ou "chose" si l'expressivité du verbe le permet.
  Par exemple : "Cuisine un truc" et "répare le truc".

Deuxième pinte : REST, SOAP, principes et enveloppes

Votre verre est vide ? Je vous propose de continuer par une Guiness car nous allons entrer dans le vif du sujet.

Si on se cantonne à cette différence entre ROA et SOA, les deux architectures semblent aussi pertinentes l'une que l'autre. Mais il y a une autre différence fondamentale : leurs relations avec les technologies du Web.

• ROA est une architecture bâtie selon un principe appelé REST qui réuni les exigences suivantes : l'adressabilité, un jeu de méthodes restreint et uniforme, et l'absence d'état.
  Or REST est aussi le principe sur lequel s'appuie l'architecture du Web "normal" (celui qui vous est familier et qui est composé en grande partie de pages HTML) et cette double proximité (technologique et architecturale) permet une utilisation pertinente et optimale de ces technologies.
• A contrario, SOA est bâtie sur des principes distincts de ceux du Web, ce qui conduit d'une part à une utilisation curieuses de ses technologies (le endpoint et l'usage abusif de la méthode POST, par exemple), d'autre part à la création de nouvelles technologies, dont l'enveloppe SOAP.

Une enveloppe ? Pour être transmis, un message informatique doit être placé dans une enveloppe qui contient notamment les informations d'adressage (comme les enveloppes de la Poste !). HTTP est un format d' enveloppe, SOAP en est un autre.

• Dans un Web Service ROA, on n'utilise que HTTP.
• Dans un Web Service SOA, on utilise les deux (en glissant l'enveloppe SOAP dans l'enveloppe HTTP).

Conclusion

Ça y est, nous sommes désaltérés et nous avons défini REST et SOAP. Vous voyez, ils sont difficilement comparables car l'un est un principe d'architecture alors que l'autre est un format d'enveloppe. D'ailleurs, il n'est pas ridicule d'imaginer un Web Service conforme à REST et utilisant SOAP comme enveloppe.

Mais REST et SOAP sont les symboles de leurs architectures respectives et celles-ci, nous l'avons vu, s'opposent fortement. Il forment donc ce couple antagoniste qui déchaîne les passions et qui suscite tant d'interrogations.