SOAP vs. REST : choisir la bonne architecture web services

Publié le Mis à jour le

De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ?

Table des matières

Introduction

De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ?

Nous parlons ici de mettre en place un protocole applicatif sur le web pour échanger de l’information avec un grand nombre de clients. Une erreur de conception ou une faille de sécurité engendreraient des coûts exhorbitants si elles devaient être corrigées. C’est une différence importante avec la problématique des EAI (Enterprise Application Integration). Une erreur de conception sur une architecture interne a un coût mais peut être corrigée, le nombre d’utilisateurs étant limité et surtout connu. Il convient donc de se poser les bonnes questions si l’on veut réussir la migration de ses applications ou de son système d’information sur le web.

Le développement de protocoles applicatifs

Rendre ses applications accessibles sur le web consiste à définir un protocole applicatif et un format de données. Un protocole applicatif est un protocole de haut niveau, orienté utilisateur. Les aspects non-fonctionnels comme le transport de l’information sont délégués aux couches inférieures comme TCP/IP ou même HTTP et SMTP.

Nous avons vu que les motivations des entreprises pour déployer des web services aujourd’hui étaient nombreuses. Quelle que soit la motivation, la problématique de l’interopérabilité est présente. Même si aujourd’hui les applications qui doivent interagir sont connues, il est fort probable qu’une nouvelle application vienne un jour s’intégrer au système.

Le format des données échangées est un autre aspect de la problématique d’interopérabilité. Il existe tellement de domaines fonctionnels différents qu’il parait difficile de spécifier un format de données qui permettrait d’exprimer efficacement tous les besoins. Le langage XML définit aujourd’hui un ensemble de règles de structuration de l’information qui nous permet d’entrevoir tous les bénéfices que l’on pourrait retirer de systèmes véritablement interopérables. Un exemple récent est le format de données RSS qui permet à différents clients de consommer un type d’information sans se soucier de la manière dont elle a été produite.

La première idée pour résoudre la problématique de l’interopérabilité des protocoles pourrait être de développer un protocole générique permettant à toutes les applications de communiquer sur le web. Ca été l’approche adoptée par XML-RPC puis SOAP. Ces spécifications utilisent le paradigme d’appel de méthodes à distance. Les messages sont envoyés sur le web dans un format XML standardisé. Cette approche a deux avantages :

  • elle facilite le travail du développeur dans la mesure ou le modèle d’interaction par appel de méthodes métiers est le même que celui de l’application (le plus souvent développée dans le paradigme objet ou procédural) ;
  • et améliore un aspect de l’interopérabilité en spécifiant le format dans lequel les informations doivent être encodées.

Cependant, on ne peut pas parler d’interopérabilité du protocole applicatif dans la mesure ou les méthodes métiers apparaissent dans l’interface publiée. Les applications discutant sur ce modèle sont fortement couplées, impliquant un investissement supplémentaire pour l’intégration de chaque nouvelle application. XML-RPC est donc de moins en moins utilisé et SOAP a su évoluer pour palier à ce problème en généralisant les modèles d’interactions :

  • communications synchrones et asynchrones ;
  • communications avec et sans état ;
  • …

Cependant, en décrivant de plus en plus exhaustivement ces différents modèles d’interaction, SOAP est devenu un framework de développement de protocoles applicatifs et non plus un protocole générique. Deux web services SOAP ne sont pas directement interopérables. Pour qu’ils le soient, ils doivent se mettre d’accord sur la façon dont ils utilisent SOAP.

Nous voyons donc qu’il parait difficile de mettre en place un protocole applicatif générique permettant d’interconnecter toutes les applications. On s’oriente plutôt vers une multiplication des protocoles applicatifs. Dans ces conditions, comment s’assurer de l’interopérabilité des web services déployés ?

Choisir SOAP ?

Nous avons vu que SOAP tient aujourd’hui plus du framework de protocoles applicatifs que du protocole générique. Sa spécification décrit l’ensemble des types d’échange possibles entre applications. L’avantage de cette approche est qu’elle permet le développement d’outils de génération automatique de web services. Cependant, deux applications qui veulent discuter entre elles doivent se mettre d’accord sur la façon dont elles utilisent SOAP, freinant ainsi l’interopérabilité.

Alors quel avenir pour SOAP ? Les entreprises semblent encore hésiter à adopter cette technologie, d’autant que toutes les spécifications WS-* ne sont pas encore finalisées.

Nous avons parlé dans l’introduction de l’interopérabilité sur les formats des données échangées et montré qu’XML répondait aujourd’hui, dans une certaine mesure, à cette problématique. Il peut être intéressant de regarder le passé d’XML pour réfléchir au futur de SOAP.

XML hérite du fomat SGML. SGML est un langage de balisage. Sa spécification décrit, à la manière de SOAP, tout ce qu’il est possible de faire dans un document SGML bien formé. Le langage a été utilisé au sein de grandes sociétés pour améliorer l’interopérabilité sur les formats de données mais ne s’est jamais imposé comme format générique pour coder l’information. Pourquoi XML semble réussir là où SGML a échoué ?

D’une part, XML est plus simple qu’SGML, facilitant le développement d’outils. Mais la différence importante avec SGML est que la spécification XML pose des contraintes sur un document bien formé plutôt que de décrire ce qu’il est possible de faire : unicode, structure figée, utilisation des URIs…

Alors le futur de SOAP est-il d’évoluer vers une spécification prescriptive plutôt que descriptive pour vraiment pouvoir parler d’interopérabilité ? Si tel sera le cas, il pourrait être intéressant de miser sur SOAP dès aujourd’hui pour se préparer à ce protocole générique dès maintenant. Mais quand cela arrivera-t-il ? Devons nous attendre encore quelques années avant d’avoir des applications totalement interopérables ? N’existe-t-il pas aujourd’hui « d’XML du protocole applicatif » ?

REST

Un style d’architecture

REST a été décrit par Roy Thomas Fielding dans sa thèse « Architectural Styles and the Design of Network-based Software Architectures ». REST est l’acronyme de Representational State Transfer. C’est un style d’architecture. Un style d’architecture est un ensemble de contraintes qui permettent, lorsqu’elles sont appliquées aux composants d’une architecture, d’optimiser certains critères propres au cahier des charges du système à concevoir.

Cela signifie que REST définit un ensemble de contraintes sur les systèmes hypermedia distribués comme le World Wide Web afin d’optimiser les qualités désirées comme la séparation des tâches, la simplicité, la généricité ou les performances réseaux. REST fournit un véritable modèle pour décrire le fonctionnement que devrait avoir le web aujourd’hui. Bien que moins formel, ce modèle peut être comparé aux paradigmes objet ou entité-association.

Architectures orientées ressource

L’information de base, dans une architecture REST, est appelée ressource. Toute information qui peut être nommée est une ressource : un article d’un journal, une photo, un service ou n’importe quel concept. Dans un système hypermedia, une ressource est tout ce qui peut être référencé par un lien.

Il est important de distinguer une ressource de sa valeur à un instant donné. Considérons par exemple la ressource « le dernier article d’un journal ». Aujourd’hui cette ressource est associée à une certaine valeur, un article particulier, mais quand un nouvel article sera publié, cette valeur changera. Cependant, il est important de noter que la sémantique de la ressource, elle, ne devra jamais changer. La valeur de la ressource devra toujours correspondre au dernier article publié.

Une ressource est identifiée par un identificateur de ressource. Il permet aux composants de l’architecture d’identifier les ressources qu’ils manipulent. Sur le web ces identificateurs sont les URI (Uniform Resource Identifier).

Enfin, les composants de l’architecture manipulent ces ressources en transférant des représentations de ces ressources. Sur le web, on trouve aujourd’hui le plus souvent des représentations au format HTML ou XML.

Une interface simple et uniforme

L’interface entre les composants est simple et uniforme. En HTTP, cette interface est implantée par les verbs GET, PUT, POST, DELETE, … qui permettent aux composants de manipuler les ressources de manière simple et « intuitive ». Lorsqu’un client web récupère un URI, il sait qu’il peut récupérer une représentation de cette ressource en déréférençant l’URI avec la méthode GET.

Le style architectural REST ajoute des contraintes supplémentaires : support du cache, communication sans état, … Je vous conseille la lecture du chapitre 5 de la thèse de Roy Fielding si vous voulez en savoir plus sur REST.

REST et les web services ?

Pourquoi parler de REST pour rendre nos applications accessibles sur le web ? Tout d’abord parce que le web doit son succès à ce style d’architecture orientée ressource. Il n’a pas été conçu comme un BUS XML pour transférer des messages entre applications.

Ensuite parceque les qualités recherchées pour le web rejoignent celles des web services : séparation des tâches, simplicité, interopérabilité, performances réseaux…

Des services web REST

Pour en finir avec les API REST

Nous avons vu que la première approche lorsqu’on voulait publier l’interface de son application sur le web était de permettre au client d’appeler les méthodes métiers à distance. On pourrait donc penser développer un service web REST en définissant un URI pour chacune de ces méthodes :

http://exemple.org/maMethode?p1=v1&p2=v2

Si les paramètres sont plus complexes, on pourrait les mettre dans le corps de la requête. Cependant, cette démarche possède, à mon avis, les mêmes défauts que le protocole XML-RPC. Nous rendons notre interface trop spécifique à notre application empêchant ainsi de faire évoluer et d’intégrer de nouveaux services facilement. En faisant de la sorte, nous contournons l’architecture orientée ressource décrit par le style d’architecture REST.

Nous avons en fait défini une API REST. On parle souvent d’API REST mais je pense que ces termes sont en fait antinomiques. On ne devrait pas parler d’API sur une architecture orientée ressource. Le terme API est réservé, à mon avis, au paradigme d’appel de méthodes. Comment alors publier son application sur le web selon le style d’architecture REST ?

Passer d’un modèle à l’autre

Pour rendre son application réellement accessible et profiter des innovations du web, il faut passer du modèle de programmation classique par appel de méthodes à un modèle orienté ressource.

La conception d’applications respectant le style d’architecture REST n’est pas (encore ?) formalisée. Mais on peut trouver sur le web de nombreux conseils et tutoriels pour concevoir un service compatible REST. Le guide le plus intéressant et complet est certainement la série d’articles de Joe Gregorio sur xml.com.

L’objectif de la démarche est de projeter un ensemble d’opérations métiers sur une architecture orientée ressource. Notre espace de départ contient une liste de méthodes. Chacune d’elle possédant une signature et, éventuellement, des exceptions en cas d’erreur. Notre espace d’arrivée est un ensemble de modèles d’interaction permettant d’implanter les fonctionnalités de l’application métier. Ces modèles d’interaction sont définis par :

  • une sémantique (description de l’interaction) ;
  • un verb HTTP (GET, PUT, POST, DELETE, …) ;
  • une ressource : URI + sémantique ;
  • des en-têtes de requête (contrôle) ;
  • un corps de requête ;
  • des en-tête de réponse ;
  • des codes erreurs éventuels.

Imaginons que nous avons sous les yeux l’interface métier de notre application, une longue liste de méthodes comme nous en avons l’habitude. A côté, nous avons une feuille blanche qu’il va falloir remplir pour définir ces modèles d’interactions. Ce n’est pas évident à priori et on est un peu perdu dans tout ce qu’il y a définir mais avec un peu de méthode, tout ça est assez simple.

Comme toute démarche de conception, la qualité du résultat dépendra de la qualité des questions que l’on se posera. Le fil conducteur de la démarche est la liste des opérations métiers. Nous allons la parcourir et nous poser les questions suivantes.

La méthode nécessite-t-elle la création d’un nouveau type de ressource ?

Chaque méthode n’entraîne pas la création d’un nouveau type de ressource. Par exemple :

Tableau 1. Deux méthodes sur une ressource web

sémantiqueméthoderequête HTTP
Récupérer un articlegetArticleGET /articles/123
Supprimer un articledeleteArticleDELETE /articles/123

Deux méthodes de notre interface métier : getArticle et deleteArticle ont été implantées sur la même ressource, /articles/123.

L’interface HTTP étant réduite à un petit nombre de méthodes, il sera parfois nécessaire de définir des types de ressources qui ne correspondent pas forcément à un objet métier dans votre application. Il ne faut pas oublier qu’une ressource est tout ce qui est identifiable par un URI. Ce n’est pas seulement des articles, des utilisateurs, des images, … cela peut tout à fait être un concept abstrait.

Quel verb HTTP utiliser ?

La sémantique des méthodes HTTP est relativement bien décrite dans la spécification HTTP/1.1. Le style d’architecture REST pose également un certain nombre de contraintes à respecter. Par exemple :

  • GET et HEAD doivent être sûres : ne pas effectuer des modifications des ressources sur le serveur qui seraient visibles par l’utilisateur ;
  • GET, HEAD, PUT et DELETE doivent être idempotente : l’exécution de 1 ou n requêtes identiques doit mener au même résultat.

La spécification HTTP/1.1 devrait toujours se trouver entre notre liste de méthodes métiers et notre feuille blanche.

Quel modèle d’URI associer à cette ressource ?

La définition d’URI est assez libre. Vous pouvez nommer vos ressources comme vous le désirez. On peut tout de même citer deux méthodes pour aider à la construction de ces URIs : Une méthode par hiérarchie et une méthode par construction.

La méthode par hiérarchie consiste à construire le chemin de l’URI en listant les différents niveaux de priorité de la ressource. Les éléments de priorité plus importante se trouveront plus à gauche (début) de l’URI. Par exemple, nous pouvons avoir un aggrégateur de quotidiens qui recence les articles publiés par des journaux. Un article « appartenant » à un journal on aurait le schéma d’URI suivant :

http://exemple.org/journal/lemonde/article/rest

Ce système de hiérarchie n’est pas toujours adapté et on peut alors construire l’URI en utilisant des paramètres :

http://exemple.org/map/color?lat=50&long=20&scale=32000

ou des URIs de matrice :

http://exemple.org/map/color;lat=50;long=20;scale=32000

Comment définir les en-têtes HTTP ?

HTTP définit un ensemble d’en-têtes permettant de décrire les ressources, les représentations ou de contrôler l’interaction. L’objectif de cet article n’est pas de lister ces en-têtes et décrire leur intérêt mais vous devriez les connaître pour plusieurs raisons.

Tout d’abord, ces en-têtes peuvent vous permettre d’économiser des nouveaux types de ressources. Si, par exemple, vous avez une ressource représentant la liste des articles d’un quotidien. Vous pourriez définir un nouveau type de ressource (nouvel URI) pour récupérer seulement les 20 derniers articles et ainsi économiser de la bande passante. Les en-têtes HTTP permettent ce filtrage (Partial GET) et vous limiterez ainsi le nombre d’URI de votre application. Remarquez cependant que l’association d’un URI unique pour cette ressource peut aussi être intéressante si vous voulez y faire référence dans un autre document.

D’autre part, ces en-têtes vous permettront d’implanter certains aspects non fonctionnels comme le cache ou l’authentification du client. Vous n’aurez pas besoin de redéfinir des protocoles.

La spécification vous guide également dans la définition de ces en-têtes. Si par exemple, vous poster un article sur un URI et qu’une ressource est créée sur le serveur, le code retour doit être 201 Created en cas de succès.

Comment choisir le format de représentation des ressources ?

J’ai gardé cette question pour la fin car elle ne pose pas réellement de problèmes. Généralement le type de représentation utilisé sera imposé par le type d’information échangé (image, article, document XML structuré, …). Si vous n’avez pas de contraintes sur le format, vous pouvez toujours choisir un format existant plutôt que de réinventer le votre. Il sera d’autant plus facile ensuite de faire interopérer les applications.

Les avantages de la démarche

Interopérabilité ?

Nous avons vu que le respect du style d’architecture REST nous permettait d’avoir une interface simple et uniforme pour chacune des ressources.

  • ressources identifiées par des URIs ;
  • ensemble de méthodes réduit (GET, PUT, POST, DELETE, …)
  • ressource manipulées par leur représentation

Cette interface uniforme nous permet-elle enfin de pouvoir parler d’interopérabilité ? Je vais vous décevoir, non, le style d’architecture REST ne nous permet pas de nous assurer que notre application sera interopérable. Pourquoi ? Tout simplement parce qu’il paraît aujourd’hui très difficile de développer des systèmes totalement interopérables. Chaque application se place dans un domaine métier précis et possède son vocabulaire. Mais le style d’achitecture REST permet de simplifier l’intégation de nouvelles applications à notre système existant.

D’une part grâce au modèle d’adressage uniforme des ressources (URI). Tous les composants du système utilisent le même outil pour nommer les choses. Il est plus facile de les manipuler. Le paradigme d’appel de méthode à distance utilise le nom des méthodes métiers pour identifier le service sur le web. L’adressage est donc totalement spécifique au service.

Ensuite, l’utilisation d’un nombre réduit de méthodes permet aux clients de savoir, avant même de contacter le service, quelles méthodes sont disponibles. De plus, la sémantique de ces méthodes étant défini clairement. Si le client veut récupérer une ressource, il y a de forte chance que la méthode GET fonctionne. Un client SOAP ne pourra jamais deviner le nom des méthodes avant d’avoir consulter le contrat WSDL.

Enfin, le fait de ne pas spécifier le format des messages échangés permet de rendre indépendant l’évolution du langage (format des données) et du support de communication (protocole). Cette indépendance permet d’interconnecter plus facilement des composants qui n’ont à priori rien à voir ensemble. L’exemple le plus connu actuellement est celui de RSS. Un client peut tirer partie de l’information fournie par un flux RSS sans se soucier de la façon dont il a été généré.

En standardisant le protocole de communication, le style d’architecture REST permet de se concentrer sur la véritable source de couplage fort : le format de données échangées. Dans son article « SOAP, REST and Interoperability » Paul Prescod cite 4 technologies pouvant aider à la résolution de cette problématique :

  • transformations XSLT ;
  • l’héritage de schémas XML
  • XML générés par des requêtes XML
  • RDF, DAML+OIL et les technologies du web sémantique

Les aspects non fonctionnels

Nous n’avons pas encore parlé des aspects non fonctionnels des web services: sécurité, qualité de services, monitoring, … Le respect d’une architecture de type REST facilite la mise en place de ces fonctionnalités pour différentes raisons :

  • les communications sans état facilitent l’implantation de ces fonctionnalités ;
  • les technologies utilisées étant largement utilisées (HTTP, URI, XML) des outils existent déjà pour gérer ces problématiques

L’utilisation de technologies existantes et largements testées sur le web est un avantage majeur de l’approche REST face à une solution SOAP qui redéfinit des protocoles par dessus HTTP (WS-*).

Conclusion

Pour conclure, nous pouvons dire que si le style d’architecture REST ne résoud pas définitivement le problème de l’interopérabilité il facilite grandement la résolution de cette problématique par les développeurs et architectes.

Enfin, on constate que plusieurs projets de spécifications de protocoles applicatifs qui suivent le style d’architecture REST ont vu le jour ces dernières années. On peut citer le projet Atom qui s’intéresse à la publication de ressources sur le web ou le projet OpenSearch d’Amazon pour la problématique de recherche en ligne et l’affichage des résultats.

Ces protocoles permettront de faciliter encore l’interopérabilité en se concentrant sur un domaine fonctionnel précis. Il sera d’autant plus facile de les interconnecter s’ils respectent tous le style d’architecture REST. L’interface uniforme de manipulation des ressources permettra de faire communiquer ces différents services très simplement à la manière des pipe UNIX.

Bibliographie