Web Service
Il existe deux grandes familles de Web Services :
- Les Web Services de type SOAP (protocole)
- Les Web Services de type REST (style d'architecture)
SOAP
- Une enveloppe contenant des informations sur le message et son acheminement
- Un modèle de données avec son format
- Le serveur expose son descripteur : WSDL (cf exemple WSDL)
- Le client récupère le descripteur pour enrichir et comprendre les données à envoyer
- Le serveur reçoit la requête du client pour envoyer une réponse.
Un protocole orienté sur du XML, le descripteur permet de voir les définitions des objets et services pouvant être consommés.
Exemple de la Requête :
La requête consiste à "Rechercher un candidat" avec les différents paramètres en entrée.
Exemple de Réponse :
La réponse est structurée avec les paramètres de retour.
REST
REST est l’acronyme de Representational State Transfer. Il correspond à un style d'architecture orienté service (ou ressource) et non un protocole. On parle de RESTful pour les systèmes qui suivent l'architecture REST.
L'architecture REST respecte un découpage client / serveur qui peut évoluer indépendamment. Elle permet d'avoir une facilité de compréhension en 30 secondes.
Les appels entre les entités sont sans état, c'est à dire qu'elles ne dépendent pas d'un contexte conservé sur le serveur. Un appel pour consommer un service avec des paramètres différents peut retourner un JSon, un fichier, un flux, une image ...
Les requêtes sont simples et sous forme URI avec des verboses HTTP, du type GET/POST/PUT/DELETE... , avec des entêtes de requête pour décrire les informations envoyées. Les requêtes sont conservées et mises en cache pour une ré-utilisation future.
Avec une approche API REST, les étapes des échanges et appels sur le web d'un client vers serveur sont les suivantes :
- Le client appel les méthodes métiers à distance en forme d'URI (avec ou sans header).
- Le client reçoit et transcrit la requête puis renvoie la réponse au client.
Exemple d'appel client :
Avantages et Inconvénients
- SOAP permet grâce au descripteur d'identifier la liste des services et objets exposés, alors que REST est sans état, ce qui lui permet d'avoir une plus grande indépendance entre le client et le serveur.
- SOAP s'adapte à différents protocoles de transport en évitant les problèmes de communication alors que REST n'utilise que le protocole HTTP.
- REST utilise l'URI comme représentation de ses ressources avec sa flexibilité d'évolution alors qu'on voit un fort couplage client / Serveur côté SOAP.
Vous pouvez trouver beaucoup d'avantages et inconvénients selon la vision de chacun.
Conclusion
De plus en plus de systèmes d'architecture se tendent vers l'architecture REST en raison de sa flexibilité et de sa facilité d'utilisation. Le protocole SOAP rencontre un problème d'interopérabilité que REST résout.
La sécurité reste un sujet problématique sur l'architeture REST, car seul le passage en HTTPS permet de sécuriser la communication.
Etant donné que REST est sans état, nous n'avons pas la description des différents services et objets exposés.
Bibliographie
Définition de Webservice : https://fr.wikipedia.org/wiki/Service_web
Définition de SOAP : https://fr.wikipedia.org/wiki/SOAP
Définition de REST : https://fr.wikipedia.org/wiki/Representational_State_Transfer
Interopérabilité : https://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
Choisir la bonne architecture : http://blog.clever-age.com/fr/2006/10/27/soap-vs-rest-choisir-la-bonne-architecture-web-services/#titre6
On parle surtout de Restful quand toutes les contraintes REST sont appliquées… et c’est rarement le cas.
Merci pour cet article synthétique et complet.
Bonjour,
Votre phrase de conclusion est fausse :
« Etant donné que REST est sans état, nous n’avons pas la description des différents services et objets exposés. »
Il est tout a fait possible et même necessaire de decrire les services et objets exposés.
Il est même possible d’integrer une documentation poussée avec par exemple les librairie de swagger.
Cordialement,
Nicolas
Le client appel les méthodes métiers à distance en forme d’URI (avec ou sans header).
Le client reçoit et transcrit la requête puis renvoie la réponse au client.
=> Le serveur reçoit et transcrit la requête puis renvoie la réponse au client.
non ?