La création et l’utilisation de web services a énormément augmenté ces 2 dernières décennies avec la démocratisation d’internet, aujourd’hui la plupart des applications web sont donc dites distribuées afin de pouvoir absorber la charge liée aux requêtes. On va alors parler de programmation distribuée, pour le web il existe 3 modèles répandus qui sont REST, SOAP et WSDL .
REST (Representational State Transfer) :
Comme dit plus haut REST est un modèle d’architecture distribuée qui va permettre la conception de services web dit client/serveur. Le client va au travers de requêtes HTTP (GET, POST, PUT et DELETE) pouvoir manipuler des données qui se trouve côté serveur, en passant par des URI (urls qui représentent chacune une ressource différente).
Ces requêtes sont dites stateless (où “sans état” pour les moins bilingue) , c’est-à-dire que peu importe quel serveur (qui peut être un serveur physique ou une VM ou un pod kubernetes ou un container docker, la liste est longue) recevra la requête il sera capable de la traiter et de répondre au client.
Pour que cela fonctionne il faut donc que le client passe toutes les informations liées aux données qu’il veut récupérer par exemple, ainsi que les informations nécessaires à l'envoi de la réponse par le serveur.
Afin de mieux comprendre le fonctionnement de reste voici une petite analogie :
Vous êtes assis à la table de restaurant (vous jouez le rôle du client côté REST), le menu va correspondre à l’ensemble des uri, chaque plat va venir avec des contraintes particulières par exemple si vous commandez de la viande vous devez préciser au serveur la cuisson, si vous commandez une glace il vous faudra préciser le parfum, sans ces informations le chef (qui est le serveur côté REST) ne sera pas capable de préparer votre plat. De la même façon, votre plat doit être associé à votre table au niveau de la commande car le cuisinier ne sera pas capable de vous le renvoyer sinon.
L’avantage majeur de fonctionner de cette façon est la simplicité d’implémentation (côté serveur) et d’utilisation (côté client) ainsi que le gain de performance qui vient avec l’utilisation directe (sans surcouche) du protocole HTTP.
SOAP (Simple Object Access Protocol) :
SOAP n’est pas vraiment un modèle d'architecture, c'est un protocole de communication qui va permettre l’échange de messages (qui suivent un syntaxe bien particulière) et qui vont être transmis via d’autres protocoles de transports (comme HTTP par exemple). La syntaxe des messages suit le format XML dont voici un petit exemple :
<?xml version="1.0" encoding="UTF-8"?><S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<S:Body>
<ns2:sayHelloToTheWorldResponse
xmlns:ns2="http://soap.bibliotheque.android.mbds.fds.edu.ht/">
<return>Hello World</return>
</ns2:sayHelloToTheWorldResponse>
</S:Body>
</S:Envelope>
Le formalisme est donc bien plus rigoureux que REST puisqu’il va suivre des normes définies mais partage avec sa caractéristique stateless.
L’un des avantages principaux de SOAP est sa flexibilité, en effet, il est indépendant des plateformes et des langages choisis et peut même être utilisé dans différents protocoles de transport comme HTTP et SMTP. Par contre, en raison de sa complexité, il alourdit énormément les échanges avec son système d’enveloppe et sa configuration minutieuse entraîne des dépendances fortes entre le client et le serveur.
WSDL (Web Services Description Language) :
WSDL est un langage qui permet de créer une description très détaillée des services web. Le fichier WSDL contient les opérations disponibles, les types de données et d’autres informations qui permettent de normaliser la communication entre le client et le serveur. Cette description se base sur le XML comme SOAP.
D’ailleurs WSDL est souvent utilisé avec SOAP, en effet, SOAP permet de définir les opérations et le format des messages mais il est nécessaire de connaître ces formats à l’avance. C’est pour cela que les services Webs utilisant SOAP donnent accès à un fichier WSDL pour connaître les spécificités du service. Il peut être également utilisé avec REST
Conclusion :
Nous avons vu que parmi ces trois technologies chacune a ses avantages et ses inconvénients. Le choix parmi ces dernières dépend de la complexité du projet et des préférences de chacun. Un déploiement rapide avec une simple compréhension du projet se dirigera plus vers REST alors qu’une implémentation pour transmettre des données complexes retranscrites entre différents environnements distincts se dirigera plus vers SOAP et/ou WSDL.
Sources :