Le Jeudi 17 juin 2010 à Paris
CC-BY-SA

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.

Commentaires

D'ailleurs, il n'est pas

pierre

Profile picture for user pierre
Jeudi 1 juillet 2010 - 14:01

D'ailleurs, il n'est pas ridicule d'imaginer un Web Service conforme à REST et utilisant SOAP comme enveloppe.

J'ai trouvé par hasard un exemple de Service Web ROA (où la requête sûre et idempotente est gérée directement par GET et non encapsulée dans POST) qui retourne les réponses dans une enveloppe SOAP : le validateur CSS du W3C !

Je ne saisis pas l'utilité mais je suis content de voir que ça existe.

Merci beaucoup pour cette

Anonyme

A
Dimanche 2 janvier 2011 - 10:32

Merci beaucoup pour cette explication!
Après une longue recherche obscure sur le net sur la différence entre Rest et Soap, votre article
a été une vraie lumière!

Merci

Merci beaucoup, explication

tarik

t
Dimanche 29 janvier 2012 - 13:31

Merci beaucoup, explication tres claire

Merci beaucoup ! Article très

Baillezon

B
Lundi 12 mars 2012 - 11:05

Merci beaucoup ! Article très clair :)

Merci beaucoup pour ce petit

idemon

i
Jeudi 19 avril 2012 - 02:44

Merci beaucoup pour ce petit bijou d'article

mérciiiiiiiiii beaucoup pour

Benhalima

B
Vendredi 20 avril 2012 - 13:45

mérciiiiiiiiii beaucoup pour cette riche et simple explication :)) 

Salut

Boens

B
Jeudi 29 novembre 2012 - 17:30

Salut

Vraiment une très bonne description avec bcq d'humour !

Idée: écrire un bouqin sur le jargon indigeste informatique SOA, DOT.NET, REST, etc. dans le style, ça ferait fureur !

en tous cas, j'achèterai !

Bravo

Bonjour, effectivement, votre

Astier

A
Vendredi 11 janvier 2013 - 08:38

Bonjour, effectivement, votre article est très clair, même si j'utilise REST et SOAP fréquemment, lorsque l'on me demande d'expliquer la différence de l'un et l'autre, j'ai toujours du mal à donner un exemple (verbes et noms), j'espère que vous ne verrez pas d'inconvénient à ce que j'utilise désormais cette "illustration" de la différence SOAP / REST.

Donc Bravo et Merci !

Une 3ieme pintes pour fêter

Richard

R
Vendredi 26 avril 2013 - 10:04

Une 3ieme pintes pour fêter cet article! Santé 

Clair, simple et concis!

Anonyme

A
Lundi 12 août 2013 - 15:43

Clair, simple et concis! Merci!

La meilleure explication que

devict

d
Mercredi 4 décembre 2013 - 00:41

La meilleure explication que j'ai trouvé !

Bonjour,

Rachel

R
Dimanche 14 décembre 2014 - 20:50

Bonjour,

Ma question est peut-être bête, mais je veux être sûre d'avoir bien compris.

Voilà j'aimerais créer un web service qui serait en fait charger de comparer des données (prix) préenregistés dans une base de données. Dans mon cas SOAP serait-il plus adapté que REST? Car si j'ai bien compris REST est préférable lorsqu'il s'agit de faire appel à une ressource spécifique préexistante. Or dans mon cas la comparaison ne se fera que sur demande du client en fonction de plusieurs paramètres que ce dernier rentrera et n'est donc pas préexistante.

Merci de votre attention!

@Astier : Vous pouvez faire

pierre

Profile picture for user pierre
Mardi 27 janvier 2015 - 06:55

@Astier : Vous pouvez faire usage de mon explication sans même citer l'article.

@Rachel : Ces recherches

pierre

Profile picture for user pierre
Mardi 27 janvier 2015 - 06:56

@Rachel : Ces recherches complexes peuvent bien évidemment être modélisée grâce au principe d'architecture REST, mais elles se formalisent difficilement en HTTP (qui n'est que l'application la plus courante de REST) car ce protocole ne propose pas une méthode idéale pour cet usage.

Ce type de recherche étant une action sûre, idempotente, avec corps de réponse, c'est tout de suite HTTP GET qui vient à l'esprit. Mais cette méthode  n'a pas de corps de requête, on est donc obligé de formaliser les critères de recherche dans l'URL (avec les query-strings) ou dans l'en-tête de requête, ce qui est contraignant et pas très correct au niveau architectural.

Une autre solution est de considérer la recherche comme une ressource Web en tant que tel. Mais, comme vous l'avez dit, elle n'est pas préexistante, il faut la créer. On formalise dans ce cas les critères de recherche dans un HTTP POST vers une ressource usine (/search par exemple), qui répond le résultat de recherche avec un en-tête Location indiquant l'URL de la ressource créée. L'avantage pour le client est u'un simple HTTP GET sur cette ressource permet de rafraîchir les résultats. Par contre, la contrainte pour le serveur est qu'il faut maintenir un grand nombre de ressources supplémentaires.

C'est cette deuxième solution que je choisirai s'il fallait absolument adopter une architecture ROA. Cependant, certains échanges sont mieux formalisées en SOA qu'en ROA. C'est pas courant, mais ça existe. C'est peut-être le cas ici.

OK, Merci Beaucoup Pierre!

Rachel

R
Samedi 31 janvier 2015 - 13:50

OK, Merci Beaucoup Pierre!

BRAVO et bien après avoir lu…

suire sandrine

s
Mardi 21 janvier 2020 - 13:24

BRAVO et bien après avoir lu plusieurs articles, et bien le votre est le seul qui m'ai permis de vraiment comprendre

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
À propos des formats de texte

HTML simple

  • Les adresses de pages web et les adresses courriel se transforment en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.