Services Web SOAP / REST

 Web Service

SOAP_REST

De plus en plus d'entreprises se tendent vers une architecture dont les données sont déportées des applications pour une meilleure distribution d'informations.
Cette approche permet de ne pas recréer les services de consommation de la base de données. Nombreux sont ceux qui rendent  leurs applications accessibles sur le web d'où l'appel à des Web Services.

WS1

Un Web Service est un protocole applicatif de haut niveau sur le web d'échange d'informations à distance avec un grand nombre de clients. Les aspects non-fonctionnels comme le transport de l’information sont délégués aux couches inférieures comme TCP/IP.
En simplifié, c'est une interface de distribution de données, qui peut répondre à plusieurs demandes HTTP et exposer différentes données venant de différentes sources (plusieurs bases de données, lire des fichiers etc...).

WS

Nous ne nous attarderons pas sur les différents types d'architecture des WebServices mais uniquement sur leurs natures.

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

SOAP, soit l'acronyme Simple Object Access Protocol, est un protocole applicatif qui est composé de deux parties :
  • Une enveloppe contenant des informations sur le message et son acheminement
  • Un modèle de données avec son format
Sa spécification décrit l’ensemble des types d’échange possibles entre applications.
Pour plus d'information, voir la définition sur Wikipédia : https://fr.wikipedia.org/wiki/SOAP.
Les échanges se font par des communications client / Serveur, dans l'ordre suivant :
  • 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.
Ce qui implique un fort couplage entre client/serveur (une modification de l'API implique ainsi une évolution côté client).
Exemple du WSDL:wsdl

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 :

req_soap

La requête consiste à "Rechercher un candidat" avec les différents paramètres en entrée.

 

Exemple de Réponse :

resp_soap

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 :

REST_Requete

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

 

 

4 commentaires

  1. On parle surtout de Restful quand toutes les contraintes REST sont appliquées… et c’est rarement le cas.

  2. 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

  3. 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 ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.