RESTful Web Services

by Christian on 22 juin, 2007

RESTful Web Services est peut-être l’ouvrage informatique de l’année.

Je vais tenter d’expliquer le plus simplement possible l’enjeu de cet ouvrage.

Internet, c’est le protocole TCP/IP. Protocole sur lequel s’appuient d’autres protocoles comme HTTP, SMTP, FTP, SNMP, TELNET, DNS, SSH, etc.

Le langage courant a tendance à confondre le Web et Internet. Or le Web, c’est uniquement l’utilisation du protocole HTTP, celui que nous utilisons avec nos navigateurs pour lire les pages HTML.
Les services web, par définition, utilisent le protocole HTTP précisément parce qu’ils délivrent des services web.

Le protocole HTPP est très simple : il permet le dialogue entre un client et un serveur. Généralement c’est un navigateur qui formule des requêtes (à chaque clic) et le serveur y répond.

Le protocole HTTP est donc un langage, et comme tout langage il a, entre autres, des verbes et des noms :

  • les méthodes HTTP sont les verbes, les principaux sont : GET, HEAD, PUT, DELETE, POST
  • les URIs, qui constituent le chemin d’accès à une ressource, sont sont les noms du langage HTTP.

Le langage du protocole HTTP constitue une enveloppe qui permet de délivrer un message, et donc un contenu, du client au serveur et réciproquement.

Le formidable avantage de HTTP est que les verbes (que les programmeurs appellent aussi méthodes ») sont peu nombreux et standardisés. Du coup, on peut facilement comprendre les requêtes qui s’expriment en HTPP :

« GET http://www.christian-faure.net/qui-suis-je/ »

Forcément, si l’on veut mettre en place des requêtes ou des services web particulièrement complexes, il y a deux choix possibles :

  • soit on mène une politique simple mais rigoureuse au niveau des URIs (on enrichi son vocabulaire et on classe ses ressources) et alors on s’oriente vers une architecture orienté ressource
  • soit on défini des verbes spécifiques, mais qui ne sont plus ceux de HTTP, et alors on s’oriente vers une architecture de style RPC qui est un protocole permettant de faire des appels de procédures sur un ordinateur distant.

Dans le deuxième cas, on ne va utiliser HTTP que pour le transport d’une enveloppe dans laquelle on aura redéfini l’appel à des verbes qui nous conviennent. Dit autrement, le verbe (et donc le sens) de la requête n’est plus porté par HTTP mais au niveau du serveur interrogé.

L’alternative entre une architecture orienté ressource comme l’est REST et une architecture RPC comme l’est SOAP pourrait être schématisé de la manière suivante :

  • soit on déporte l’intelligence sur les ressources
  • soit on déporte l’intelligence sur des procédures (verbes) spécifiques et non-standards.

Les grands marchands du web comme Amazon, par souci de simplicité et d’interopérabilité sont plutôt portés vers l’architecture REST, tandis qu’au sein des entreprises on s’échine à faire toujours plus compliqué avec du RPC-SOAP-WSDL : il faut bien faire vivre les éditeurs et les SSII.

Je terminerai cette note en précisant que l’intérêt de REST, en tant qu’architecture orientée ressource, va dans le sens d’une promotion de RDF, précisément en tant qu’environnement de descriptions de ressources.

[Update] Il faut lire la note de David sur REST et les commentaires de Got à cette note, en attendant de voir leur développement sur le sujet sur leur blogs respectifs.

Print Friendly
Signaler sur Twitter

{ 8 comments… read them below or add one }

Christophe juin 22, 2007 à 5:19

Excellente mise au point ! Autant la distinction web/internet est assez évidente, autant le fossé qui sépare REST et SOAP est mal compris des propres acteurs d’internet. Je sais maintenant où trouver les mots justes et concis pour l’expliquer.

Répondre

got juin 22, 2007 à 11:01

Je ne suis pas entièrement convaincu qu’il faille jeter définitivement SOAP. Effectivement, REST offre une simplicité d’utilisation supérieure à SOAP et je préfère a-priori ce protocole à SOAP (avec Xforms, c’est du bonheur). Pour autant, je limiterais ton propos (même s’il me semble que ton avis est en réalité plus pesée). Tout d’abord, Amazon offre les deux types de protocoles pour ces web-services, tu peux soit faire du SOAP, soit du REST.
De plus, je ne sais pas si l’argument des verbes propriétaires est vraiment tenable. Le principe de verbes existe aussi en REST, ce sont les arguments qui vont être véhiculés dans l’URL, par exemple : http://oai.enc.sorbonne.fr/oai2.php?verb=ListRecords&metadataPrefix=oai_dc (OAI : http://www.openarchives.org, pour les archives ouvertes scientifiques) ou http://api.flickr.com/services/rest/?method=flickr.photos.getInfo&api_key=ff2f2127e2529a9e261b4c9e0300deb0&photo_id=379686743 (Flickr). Comme on le voit dans cet exemple, il ne me semble pas que c’est HTTP qui porte le sens, mais l’URL.
Par ailleurs, le principe de WSDL, qui permet de décrire le service en XML (donc dans une syntaxe normalisée), me paraît essentiel pour assurer la pérennité des échanges. Il n’existe aujourd’hui, me semble-t-il, aucun moyen pour décrire un service en REST.
Je vois deux autres intérêts à SOAP : tu peux agréger plusieurs verbes dans une enveloppe SOAP (dans une syntaxe normalisée 😉 ) et tu peux avoir un fichier en pièce jointe, ça peut servir.
Enfin, par rapport au Web sémantique, il existe un groupe d’intérêt qui réfléchit au problème : http://www.w3.org/2002/ws/swsig/ .
En revanche, je suis tout prêt à en apprendre plus sur REST, tu me prêteras le bouquin 😉

Répondre

Christian juin 22, 2007 à 11:31

Bon commentaire, merci Got d’être toujours aussi aiguisé.

Alors il faut que je précise ce qui se passe quand les URI contiennent des arguments : c’est précisément parce que le verbe est porté par HTTP qu’il va y avoir un enrichissement de l’URI par les « scoping informations ».
De fait c’est bien le respect de HTTP qui amnène à une valorisation des ressources. C’est pourquoi une architecture REST conduit à une architecture orientée ressource. CQFD

Sinon, pour le livre, tu peux toujours fumer : je ne prête jamais un livre ! (C’est d’ailleurs pourquoi je n’aurai jamais pu être bibliothécaire). Mais tu peux cliquer sur le lien de la note et l’acheter sur amazon, çà me fera un peu de monnaie 🙂

Répondre

David, biologeek juin 23, 2007 à 10:01

Aaaaargh. J’étais justement en train de rédiger un billet sur ce livre :-).

Remarque, les thèmes que j’allais aborder compléteraient à merveille cette explication, je vais peut-être le terminer en fin de compte…

Répondre

got juin 23, 2007 à 10:14

Tu ne peux pas dire que SOAP ne respecte pas HTTP, puisque l’enveloppe SOAP utilise le POST. La différence se situe précisément sur ce point. Il existe une logique entre toutes les recommandations du W3C. Si tu couples Xforms, HTTP et SOAP, tu obtiens une architecture qui tient vraiment la route, mais il est vrai qu’actuellement les navigateurs ne savent pas gérer ces trois normes en natif et on est obligé de faire le traitement côté serveur, alors que REST va le faire côté client. Bref, il existe à mon avis des cas de figure où SOAP est mieux que REST et inversement. Il ne faut pas à mon avis les opposer, mais plutôt essayer de réfléchir à la meilleure utilisation des deux protocoles en fonction du cas de figure.

Répondre

Christian juin 23, 2007 à 10:29

@ David : on compte bien sur ton billet, et on s’en réjouit d’avance 🙂
@ Got : bien sûr que SOAP respecte HTTP, le problème c’est qu’il rajoute une enveloppe à l’enveloppe HTTP : bonjour les poupées russes :-). Pour aller plus loin dans la distinction entre REST et SOAP (WS-*) voir ce billet, signalé par Karl dans un commentaire sur le blog de David.
Au fait Got, je suis preneur d’une petite note sur l’architecture Xform/HTTP/SOAP sur lespetitescases

Répondre

Got juillet 2, 2007 à 2:50

Un article de IBM developper Works devrait t’intéresser : « Enable REST with Web services, Part 1: REST and Web services in WSDL 2.0 », http://www.ibm.com/developerworks/webservices/library/ws-rest1/ . Comme son nom l’indique, il essaye de voir s’il est possible et comment réconcilier REST et les Web services et surtout de décrire un service en REST avec WSDL ce qui était un de mes reproches.

Répondre

Christian juillet 7, 2007 à 2:40

Concernant les Architectures REST orientés ressources, on préfèrera WADL à WSDL.

Répondre

Leave a Comment

{ 4 trackbacks }

Previous post:

Next post: