Internet, Programmation Services Web : REST face à SOAP
webservices

Internet, Programmation

Services Web : REST face à SOAP

Introduction

Les services Web sont devenus, depuis quelque temps, la norme de facto pour intégrer des applications internes ou offrir une interface externe aux clients. Il est plus facile de transmettre des données entre différentes plates-formes en utilisant ce moyen; plus facile de composer le message, plus facile à déboguer, plus facile à comprendre. Ainsi vous pouvez intégrer des parties du système écrites en Java, .NET, PHP etc. en utilisant un protocole bien connu et des messages textes (généralement en XML). Les codages binaires (c’est à dire spécifiques, non-textuels) sont véhiculés plus rapidement, mais elles sont réservées à certaines plateformes. Vous ne pouvez pas utiliser des formats binaires .NET pour communiquer avec une application Java. Voici ce dont il s’agit avec RPC et, plus récemment, avec SOAP : l’intégration de modules via des services Web.

Points communs

Les deux protocoles2 fonctionnent parfaitement avec HTTP3 , le protocole de transfert de données entre clients et serveurs utilisé sur le Web. HTTP est un protocole simple, bien connu, donc cela peut être considéré comme un avantage : facile à comprendre, implémenté sur la plupart des plateformes, il n’est pas d’habitude bloqué par les pare-feu.
Les messages sont dans le format XML1, un format texte facile à comprendre.

Pourquoi choisir REST ?

REST est léger et simple : les messages sont courts, faciles à décoder par le navigateur et par le serveur d’application.

REST est auto-descriptif : vous pouvez naviguer à travers ses ressources comme vous le feriez avec une page Web. Il y a une URL intuitive unique pour chaque ressource. On peut facilement en déduire la structure des ressources sans avoir besoin de beaucoup de documentation.

REST est « stateless » (il n’est pas adapté aux transactions longues et complexes) : il est parfait pour les opérations simples (créer, lire, mettre à jour, effacer).

REST peut être géré en cache (antémémoire) : les ressources simples, identifiables sont aussi faciles à mettre en cache qu’un article sur un site Internet. L’adaptation aux variations de charge et la performance que cela apporte ne doivent pas être négligées.

Pourquoi ne pas choisir REST ?

REST est généralement critiqué pour son manque de complexité exigée pour les transactions d’affaires : sécurité, support transactionnel.
REST est considéré en quelque sorte comme un artifice du « web 2.0” plutôt qu’une vraie solution d’entreprise.

Pourquoi choisir SOAP ?

SOAP a été conçu comme un mécanisme d’appel de procédure distante. On utilisera SOAP en toute confiance pour appeler une méthode sur un autre serveur et recevoir la réponse dans un mode contractuel.

SOAP supporte le transactionnel : il supporte les transactions ACID, de sorte qu’il peut gérer un commit à deux phases sur des ressources transactionnelles distribuées (WS – Atomic Transactions ).

SOAP a quelques caractéristiques de sécurité supplémentaires : il supporte l’identification à travers des intermédiaires, plus que SSL ne peut offrir5.

SOAP est formel : les méthodes à distances et leurs résultats sont bien spécifiées via des contrats.

SOAP est fiable : il dispose des mécanismes pour garantir la fiabilité de la transmission et de la réception de données.

SOAP offre de nombreux outils : étant donné qu’il a d’abord été publié par Microsoft en 1998, beaucoup de fournisseurs ont créé des outils au fil des années. Aussi la plupart des plates-formes de développement sont pourvues d’un moyen facile d’exploiter une fonction distante via SOAP.

Pourquoi ne pas choisir SOAP ?

SOAP a été à l’origine imaginé pour faire un protocole RPC qui passe les pare-feu (remplaçant donc le DCOM de Microsoft avec XML sur HTTP).

SOAP est considéré trop complexe et verbeux pour les besoins ordinaires.

SOAP est d’habitude utilisé dans des framework propriétaires. Bien que cela fournisse un point d’entrée apparemment plus facile (quelquefois basé sur un assistant) pour créer des services Web, sa complexité rend ardu le débogage des messages, donc tout l’avantage du XML lisible par l’utilisateur est perdu assez vite.

SOAP nécessite une compréhension claire des APIs spécifiques au site. Son utilisation est comparable à l’utilisation d’un nouveau framework. Il demande du temps et de la documentation.

L’interopérabilité de SOAP a diminuée au fil des années, avec des normes différentes et les implémentations des fournisseurs de logiciels. Désormais il est certain que REST est de loin plus interopérable.

Dernières réflexions

Il est généralement admis que l’objectif de SOAP était seulement d’aller à mi-chemin dans l’utilisation du Web comme un modèle pour la distribution de données : protocole HTTP et format XML. REST a poursuivi le chemin en ajoutant le dernier élément qui manquait à SOAP : le simple et efficace schéma d’adressage URL au sein de l’espace de nommage global du Web. N’importe qui sachant utiliser le Web peut utiliser REST. C’est aussi simple que cela.

Une tendance claire dans l’industrie est l’augmentation des APIs REST (les géants du Web, Yahoo, Google, Amazone et eBay offrent à leurs clients des APIs REST). SOAP a commencé à s’effondrer sous son propre poids et restera probablement comme une solution réservée à certains scénarios d’entreprises spécifiques (tels que les transactions bancaires).

Beaucoup de caractéristiques pour lesquelles SOAP est préféré existent en fait dans REST (bien que cela prenne un peu plus d’effort initial pour les mettre en oeuvre) : la sécurité via HTTPS, l’authentification via basic auth, les sessions via les cookies. Cependant, jusqu’à ce que ces besoins et leurs solutions deviennent bien connus et faciles à aborder par les développeurs, SOAP aura sans aucun doute sa place.
Dans la plupart des scénarios, REST est la voie à prendre. Considérez seulement SOAP si vous avez besoin (ou si vous croyez que vous avez besoin) de certaines fonctions WS-* spécifiques (transactions distribuées, fédération d’identification, routage de message).

___________________
1 Il y a une différence subtile: alors que RPC traite de l’appel de fonctions distantes, SOAP s’occupe plutôt de transférer des messages.
2 Techniquement, REST est seulement une architecture, pas réellement un protocole alors que SOAP est un Framework de protocole, plutôt qu’un protocole concret.
3 SOAP peut travailler aussi sur d’autres protocoles, tels que SMTP, bien que ce soit rarement vu en pratique. REST fonctionne seulement sur HTTP.
4 REST n’est pas limité à XML: beaucoup d’implémentations utilisent JSON, un format encore plus léger, moins verbeux.
5 Bien qu’Open ID devienne une alternative pour la fédération d’identification dans le monde de REST

Laisser un commentaire

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

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Facebook
Google+
https://blog.beleringenierie.com/2011/04/10/services-web-rest-face-a-soap/">
Twitter