REST et SOAP sont des éléments souvent comparés l'un à l'autre dans la conception des applications client-serveur, mais c'est une erreur.

Pourquoi utiliser un web service ?

De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ?

Nous parlons ici de mettre en place un protocole applicatif sur le web pour échanger de l’information avec un grand nombre de clients. Une erreur de conception ou une faille de sécurité engendreraient des coûts exhorbitants si elles devaient être corrigées. C’est une différence importante avec la problématique des EAI (Enterprise Application Integration). Une erreur de conception sur une architecture interne a un coût mais peut être corrigée, le nombre d’utilisateurs étant limité et surtout connu. Il convient donc de se poser les bonnes questions si l’on veut réussir la migration de ses applications ou de son système d’information sur le web.

Les services Web

Globalement, un service Web est une méthode de communication entre deux applications ou appareils électroniques, via le Web. Il existe deux types de services Web: Simple Object Access Protocol (SOAP) et Representational State Transfer (REST).

Le protocole SOAP (Simple Object Access Protocol)

SOAP est une spécification d’un protocole de communication standard (un ensemble de règles) pour l’ échange de messages XML. SOAP repose sur différents protocoles de transport, tels que HTTP et SMTP. (Utilisation du standard XML pour l'échange des messages) 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

L'architecture REST (Representational State Transfer)

REST, quant à lui, décrit un ensemble de principes architecturaux par lesquels les données sont transmises sur une interface standard (telle que HTTP). REST ne contient une couche supplémentaire de messages et s’intéresse davantage aux règles de conception de services sans état (stateless). Un client accède à la ressource via un URI unique et une représentation de la ressources est ensuite retournée. Avec chaque nouvelle représentation de la ressource, on dit que le client transfère l’état. En accédant aux ressources RESTful avec le protocole HTTP, l’URL de la ressource sert d’identifiant de la ressource et GET, PUT, DELETE, POST et HEAD sont les opérations standard HTTP à appliquer sur cette ressource. Contrairement à SOAP, REST n'a pas à utiliser XML pour fournir la réponse. Vous pouvez trouver des services Web en REST qui ont comme sortie des données au format CSV (Command Separated Value), JavaScript Object Notation (JSON) ou encore Really Simple Syndication (RSS). Vous pouvez donc obtenir la sortie dont vous avez besoin sous une forme qui est facile à analyser avec le langage dont vous avez besoin pour votre application.

Le choix entre SOAP et REST

Le plus grand avantage de REST est le fait de comprendre que 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.

Tableau récapitulatif des différences majeures entres SOAP et REST

#	SOAP	REST
1	SOAP est un protocole de message basé un le XML	REST est une architecture
2	SOAP permet que le format XML (WSDL)	REST propose différents formats XML, JSON, CSV, etc
3	SOAP utilise des services en appelant des RPC methodes	REST utilise des services en appelant des URLs (PUT, GET, POST, DELETE)
4	Non dépendance par rapport à la langue, la plate-forme et le transfert (SMTP, HTTP, etc)	REST nécessite l'utilisation de HTTP uniquement
5	SOAP requière plus de bande passante et de ressources que REST	REST requière moins de bande passante et moins de ressources que SOAP
6	SOAP est plus lent que REST	REST est plus rapide que SOAP
7	JavaScript peut appeler SOAP mais l'implémentation est difficile	Une API peut facilement être appelée en JavaScript