Overblog Suivre ce blog
Editer l'article Administration Créer mon blog

Architecture logicielle : Web services SOAP ou REST ?

3 Mai 2012 , Rédigé par benkirane Publié dans #Architecture logicielle

Le développement de services Web est devenu depuis quelques années un enjeu primordial pour certaines entreprises. Il permet, entre autres, de mettre à disposition à d'autres des services spécifiques à son domaine d'activité qu'ils soient gratuits ou, pour une meilleure qualité de service, payants. Les services Web offerts par google maps, par exemple, sont devenus en quelques années des standards dans le domaine de la géolocalisation. Pour leur mise en œuvre, plusieurs méthodes sont possibles: la traditionnelle basée sur SOAP et celle qui est en constante croissance, basée sur une architecture de type REST. Cet article ne se veut pas une éloge pour l'une ou l'autre des méthodes, il en résume les avantages et inconvénients. Le choix de l'utilisation de l'une ou l'autre doit bien être l'aboutissement d'une étude des besoins de chaque entreprise en fonction de son contexte propre.

SOAP

Au départ, les architectes d'entreprise ont privilégié les services Web de type SOAP. Les principaux avantages de ce protocole étant:
  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme où ils sont déployés,
  • son extensibilité,
  • l'utilisation du standard XML pour l'échange des messages,
  • le contenu des messages échangés qui incluent le format d'échange cela permet d'avoir un contrat personnalisé entre le fournisseur et le consommateur du service,
  • l'utilisation du protocole HTTP pour le transport qui permet de s'affranchir des problématique de firewalls: en réalité SOAP est indépendant de la couche de transport puisqu'il l'a redéfini (entête, format d'échange, type des données échangées, ...). Cependant, HTTP est le protocole de transport le plus largement utilisé par SOAP.

Ces avantages devaient permettre une interopérabilité entre des applications hétérogènes développées en Java, .NET ou PHP. Cependant, les architectes ont été confrontés à des problèmes parmi eux:

  •  SOAP étant extensible, plusieurs standards sont apparus, regroupés sous la forme WS-* :

    WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, etc. Leur nombre croissant a abouti à l'augmentation de la complexité perçue de SOAP. De plus, des différences d'implémentations ont aboutis à des problèmes d’interopérabilité entre applications hétérogènes. 
  • pour que les applications puissent interagir entre elles, la description des Web services en WSDL et la définition d'un dictionnaire de données sont nécessaires dans l'entreprise. Cependant, dès qu'une erreur de conception de ce dictionnaire apparaît, l'implémentation des services Web devient problématique et couteuse. Ajoutée à cela, le coût de mise en œuvre des fichiers de description des services Web (le WSDL) et des fichiers de données (XSD). En résumé, le coût de mise en œuvre est souvent très élevé.
  • La conception des services Web en elle-même. Si un service est mal conçu, et cela peut arriver très vite, le nombre de données qu'il renvoie peut-être très important. Ajoutée à cela, la verbosité de SOAP, très rapidement, des problèmes de performance sont rencontrés qui induisent souvent à une remise en cause de la conception elle-même des services.

Le coût et la complexité d'implémentation générés par les inconvénients de SOAP ont remis en cause, complètement, les avantages de son utilisation. Les réseaux sociaux, dans un premier temps, avec leur volume de données échangées puis les autres entreprises, ensuite, se sont positionnées sur un autre moyen de mettre en œuvre des services Web moins couteux, plus simple à implémenter et surtout plus efficace. Cette méthode qui n'est pas nouvelle puisqu'elle est basée sur les fondamentaux du protocole HTTP est l'architecture REST (cf. mon billet précédent sur ce thème).

REST

Les architectures de type REST deviennent, de plus en plus, des standards dans les entreprises aujourd'hui. La plupart des consultants en informatique de gestion vous le diront. Cependant, au delà de l'effet de mode, la mise en œuvre de services Web basée sur cette architecture a de quoi séduire. Les principales motivations pour le choix de cette architecture sont:

  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme sur laquelle ils sont déployés,
  • la plus grande simplicité d'implémentation car la couche transport n'a pas besoin d'être redéfinie et il n'est plus nécessaire de créer un dictionnaire de données comme on le fait avec SOAP.
  • la non intégration du format d'échange au sein des messages. Cela induit une verbosité beaucoup plus faible et donc une performance accrue et une plus grande souplesse dans l'implémentation,
  • l'utilisation de multiples formats pour l'échange de données (XML, JSON, HTML),
  • qu'elle est plus proche de la conception et de la philosophie initiale du Web (URI, GET, POST, PUT et DELETE),
  • pas de gestion d'états du client sur le serveur.

Comme les services Web de type SOAP, ceux basés sur l'architecture REST ont le gros avantage d'être interopérables et indépendants de leur environnement de déploiement avec, en bonus, de meilleures performances. Cependant, ils ont des défauts conséquents à leur adhésion au protocole de transport HTTP:

  • une limitation en matière de sécurité,
  • il n'est pas fiable et ne garantit pas la bonne transmission des messages,
  • la limitation en terme d'actions possibles (CRUD uniquement),
  • les navigateurs actuels implémentent mal les opérations PUT et DELETE.
Dans la réalité, ces limitations ne sont pas vraiment un frein. La sécurité peut-être introduite de plusieurs façons différentes (tokens d'authentification, HTTPS, des outils comme Spring security en java). Les problèmes de standardisation des navigateurs sont détournés par surcharge de la méthode POST. Le vrai frein au choix de REST pour la mise en oeuvre de Web Services est le besoin propre à chaque application.

Conclusion

Internet existe depuis plusieurs décennies maintenant et, avec le retour des architectures REST, on peut se rendre compte que pendant ces années, beaucoup ont perdu les fondamentaux même du protocole HTTP. Les navigateurs, eux-mêmes, ne l'implémentent pas convenablement, ce qui est un comble. De mon point de vue, en tant que professionnel du Web, le plus grand avantage de REST est de revenir aux sources de la toile comme l'ont pensé ses créateurs. Le Web n'est pas un ensemble de pages HTML mais un ensemble de ressources dont l'une des représentations est le HTML. D'autres sont possibles comme JSON, XML, PDF, etc... Sur ces ressources, il est possible d'effectuer 4 opérations principales qui sont GET, POST, PUT et DELETE, du CRUD en résumé.

Ceci est important, lorsqu'on réfléchit au choix d’architecture logicielle. Si vos services Web sont orientés action (plus complexes que les opérations simples du CRUD) et qu'ils nécessitent une sécurité élevée ou un contrat rigide d'échange, SOAP sera, souvent, le protocole le plus adapté.

Si vos services Web sont orientés ressources avec des opérations simples sur celles-ci, REST sera le choix le plus judicieux. Le développement de ces services se focalisent plus sur l'identification des ressources. REST impose le reste de la conception par la possibilité d’implémenter les 4 actions ou verbes (HTTP) du CRUD.

 

Partager cet article

Repost 0

Commenter cet article