Méthodes d'intégration : avantages et inconvénients de REST avec SOA
Aucune méthode d'intégration ne va sans son lot d'échecs et de succès. Voici à quoi ressemblerait le meilleur de l'intégration REST avec SOA.
Quels sont les avantages et les inconvénients de l'intégration REST avec SOA ? Avant d'entrer dans les détails de cette question, je veux d'emblée clarifier un point : Les architectures REST (REpresentational State Transfer) et SOA (Service-Oriented Architecture) ne constituent pas des méthodes d'intégration concurrentes. Certains font instantanément l'amalgame entre l'architecture SOA et le protocole SOAP (Simple Object Access Protocol), mais en réalité, SOA ne préconise aucune technologie particulière. SOA se résume à une architecture de services ; vous êtes totalement libre de choisir le mode d'interaction de ces services, même si REST demeure un excellent candidat.
Côté positif, parmi les contraintes d'interfaçage uniforme de l'architecture REST, toutes les ressources doivent disposer d'un URI (Uniform Resource Identifier) et répondre aux opérations HTTP (HyperText Transfert Protocol) GET, PUT, POST (Power-On Self-Test ; autotest à la mise sous tension) et DELETE. Ces opérations correspondent globalement à la doctrine de manipulation des données CRUD (Create, Read, Update, Delete : créer, lire, mettre à jour, supprimer). Si les commandes POST et UPDATE ne sont pas totalement équivalentes, elles peuvent tout à fait s'inscrire dans cette optique.
Pourquoi REST constitue une méthode d'intégration efficace
En quoi est-ce une bonne chose ? Selon mon expérience, la grande majorité des services utilisés par une entreprise concernent en principe la récupération des données. Aussi, plutôt que de définir toute une série d'API (interfaces de programmation d'application) personnalisées de la forme getThisAndThat(...), mieux vaut utiliser l'opération HTTP GET. Et ce fonctionnement ne repose pas sur la seule utilisation de l'opération GET, mais sur sa combinaison avec des URI.
L'URI constitue la clé unique d'une ressource spécifique. Si cette ressource affiche des relations avec d'autres ressources – par exemple, une Commande associée à une Personne – les URI jouent le rôle des clés étrangères qui permettent de parcourir ces relations. Sachant que l'architecture REST tire parti de la technologie d'hypermédia en tant que moteur de l'état des applications HATEOAS (Hypermedia As The Engine Of Application State), il ne reste plus à l'utilisateur qu'à extraire l'URI de la représentation de la ressource et d'exécuter une opération HTTP GET pour accéder aux informations.
La seule élimination de WSDL et SOAP ne donne pas une architecture REST.
Parallèlement, la technologie HATEOAS est essentielle à la flexibilité. Que se passe-t-il lorsque la structure doit changer ? Si le parcours vers ces relations est spécifié dynamiquement via des liens intégrés à la réponse, vos utilisateurs n'ont pas forcément besoin de changer. De plus, ne pas être contraint à une définition et une validation d'interface rigides permet d'ajouter des éléments en fonction des besoins. Si c'est important pour l'utilisateur, il modifiera son code ; mais ce serait le cas avec n'importe quelle autre technologie.
L'approche HATEOAS est très importante mais malheureusement souvent oubliée. Beaucoup pensent que l'architecture REST consiste simplement à se débarrasser de l'enveloppe SOAP et du langage WSDL (Web Services Description Language), mais ce n'est pas le cas. L'architecture REST ne nécessite aucun langage de description d'interface, comme WSDL, et fonctionne parfaitement non seulement avec le langage XML (eXtensible Markup Language), mais aussi avec JSON (JavaScript Object Notation) et tout autre type de support que vous souhaitez prendre en charge.
C'est là sa grande force ; elle favorise la compatibilité au niveau de la couche de présentation, qu'il s'agisse d'une application bureautique, Web ou mobile. La seule élimination de WSDL et SOAP ne donne pas une architecture REST. Dans l'exemple Personne/Commande ci-dessus, le retour d'un code XML pour une Commande comportant un élément appelé <ID_Personne> ne rend pas le fonctionnement compatible REST, ou « RESTful », si l'utilisateur n'est pas en mesure d'effectuer une simple opération HTTP GET sur la valeur de cet identifiant. Un simple code XML/HTTP ne donne pas une architecture REST.
Inconvénients de REST
Lors de l'examen de méthodes d'intégration, le plus important consiste à ne pas perdre de vue que l'architecture REST est bien plus axée sur un modèle orienté ressources que sur un modèle orienté fonctions. Quand j'entends le mot « service », j'ai tendance à raisonner « fonction » et j'ai également observé cette tendance chez de nombreuses personnes. Et quand j'entends « ressource », je pense généralement « données ». Dès que vous optez pour un service axé davantage sur les fonctions que sur les ressources, il peut s'avérer compliqué de le représenter dans le cadre d'une approche REST.
Par exemple, quelle est la meilleure façon de présenter une logique de calcul ? Dans un modèle axé davantage sur les fonctions, tel que SOAP, vous allez créer une opération de calcul. Dans une architecture REST, l'approche adaptée pourra consister à obtenir en priorité la valeur résultant du calcul ; par exemple GET /commande/12/prix. Si résoudre ce cas est simple, attendez-vous à en rencontrer des plus difficiles. Parallèlement, ce modèle orienté ressources implique la création d'un modèle de ressources robuste. Et la tâche n'est pas facile. Bien sûr, aucune des deux approches ne dispose d'un modèle fonctionnel robuste.
Et aussi
Autre défi de l'architecture REST, elle peut conduire à un modèle plus fin. Quand fournissez-vous un lien dans vos réponses, plutôt que les données réelles issues d'une relation ? Argument à décharge, il s'agit d'un choix conceptuel qui reste possible. Ainsi, rien ne vous empêche de renvoyer un lien à suivre, en même temps qu'une partie des données elles-mêmes. Considérez l'opération comme une jointure à laquelle s'ajouterait le renvoi d'une clé étrangère permettant d'obtenir davantage de données.
Enfin, si la simplicité de REST s'avère plutôt attrayante, elle rend parallèlement plus difficile la création d'outils adaptés. Si vous envisagez des services SOAP ou XML pour ces outils, WSDL ou XSD (ou les deux) sont essentiels à leur mise en oeuvre.
Avec REST, l'affaire est toute autre... Certains outils accepteront les POJO (Plain Old Java Object) ou un schéma relationnel, qu'ils exposeront via REST. De même, rien ne vous empêche de définir un schéma XML pour une représentation XML renvoyée par un service RESTful, et d'utiliser un genre d'API JAXB pour la conversion en Java. Ne perdez cependant pas de vue que s'appuyer sur ces fichiers – notamment si le schéma est repris au moment de l'exécution – génère des contraintes supplémentaires susceptibles de rendre plus coûteuse la prise en charge des modifications.
Globalement, je suis content que la question se soit posée de cette manière, et non du point de vue du classique débat SOAP ou REST. Dans des décisions de ce type, rien n'est absolu ; il y a des avantages et des inconvénients. Quiconque a travaillé dans un service informatique connaît les passions que déchaîne chaque approche et les nombreux exemples de réussites et d'échecs. Il est bien plus important de comparer les forces et les faiblesses de chaque approche à celles de votre organisation.
