Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Comprendre SOAP et REST et leurs diffèrences

Par Samir SELLAMI Publié le 06/10/2016 à 16:33:39 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Simple Object Access Protocol (SOAP) et Representational State Transfer (REST) ​​sont deux solutions pour un même problème: comment accéder à des services Web. Le choix d'abord peut sembler facile, mais parfois il peut être étonnamment difficile.

SOAP est un protocole d'accès aux services Web basés sur des normes qui existe depuis un certain temps et bénéficie de tous les avantages de l'utilisation à long terme. Initialement développé par Microsoft, SOAP est vraiment pas aussi simple que son acronyme le semble.

REST est le nouveau venu. Il vise à résoudre les problèmes rencontrés avec SOAP et fournir une méthode vraiment simple, d'accéder à des services Web. Cependant, SOAP est parfois plus facile à utiliser; REST peut causer parfois quant à lui ses propres problèmes. Les deux techniques ont des problèmes à prendre en compte au moment de décider quel protocole utiliser.

Avant d'aller plus loin, il est important de préciser que même si SOAP et REST présentent des similitudes en utilisant le protocole HTTP, SOAP est un ensemble plus rigide de modèles de messagerie que REST. Les règles de SOAP sont importantes parce que sans ces règles, vous ne pouvez pas atteindre tous les niveaux de la normalisation. REST a une architecture qui ne nécessite pas de traitement et qui est naturellement plus flexible. SOAP et REST reposent sur des règles bien établies que tout le monde a accepté de respecter dans l'intérêt de l'échange d'informations.

Introduction à SOAP

SOAP repose exclusivement sur XML pour fournir des services de messagerie. Microsoft a initialement développé SOAP pour remplacer des technologies plus anciennes qui ne fonctionnent pas parfaitement sur le web tels que le Distributed Component Object Model (DCOM) et le Common Object Request Broker Architecture (CORBA). Ces technologies échouent parce qu'elles comptent sur la messagerie binaire; la messagerie XML employée par SOAP fonctionne mieux sur le web.

Après une première version, Microsoft a présenté SOAP à l'Internet Engineering Task Force (IETF) où il a été normalisé. SOAP est conçu pour soutenir l'expansion, il a donc toutes sortes d'autres sigles et abréviations qui y sont associés, tels que WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction et WS-RemotePortlets.

Le fait est que SOAP est fortement extensible, mais vous pouvez utiliser uniquement les parties dont vous avez besoin pour une tâche particulière. Par exemple, lorsque vous utilisez un service Web public qui est librement accessible à tout le monde, vous n'avez plus vraiment besoin de WS-Security.

Le XML utilisé pour envoyer des requêtes et recevoir des réponses dans SOAP peut devenir extrêmement complexe. Dans certains langages de programmation, vous devez construire ces requêtes manuellement, ce qui devient problématique parce que SOAP ne tolère pas les erreurs. Cependant, d'autres langages peuvent utiliser des raccourcis que SOAP fournit; qui peut vous aider à réduire l'effort nécessaire pour créer la requête et pour analyser la réponse. Et quand on travaille avec les langages comme le .NET, vous ne voyez même le XML.

Une partie de cette magie réside dans le WSDL (Web Services Description Language). Il s'agit d'un autre fichier qui est associé à SOAP. Il donne une définition de la façon dont le service Web fonctionne, de sorte que lorsque vous créez une référence à celui-ci, l'IDE peut complètement automatiser le processus. Donc, la difficulté d'utiliser SOAP dépend dans une large mesure du langage que vous utilisez.

L'une des caractéristiques les plus importantes de SOAP concerne la gestion des erreurs. S'il y a un problème avec votre requête, la réponse contient des informations d'erreur que vous pouvez utiliser pour résoudre le problème. Étant donné que vous pourriez ne pas pouvoir accéder au service Web, cette particularité est extrêmement important; sinon vous devriez deviner les raisons pour lesquelles vos requêtes ne fonctionnaient pas. Le rapport d'erreurs fournit même des codes normalisés de sorte qu'il est possible d'automatiser des tâches de gestion des erreurs dans votre code.

Une autre caractéristique intéressante de SOAP est que vous ne devez pas nécessairement l'utiliser avec le protocole HTTP(HyperText Transfer Protocol). Il existe actuellement une possibilité pour l'utilisation de SOAP à travers le protocole SMTP (Simple Mail Transfer) et il n'y a aucune raison que vous ne puissiez pas l'utiliser avec d'autre protocoles de transfert. C'est ce que font les développeurs dans certaines languges, comme Python et PHP.

Introduction à REST

De nombreux développeurs ont trouvé SOAP encombrant et difficile à utiliser. Par exemple, travailler avec SOAP en JavaScript signifie écrire une tonne de code pour effectuer des tâches extrêmement simples parce que vous devez créer à chaque fois la structure XML requise.

REST offre une alternative plus simple. Au lieu d'utiliser XML pour faire une demande, REST repose sur une simple URL. Dans certaines situations, vous devez fournir des informations supplémentaires de façon particulière, mais la plupart des services Web qui utilisent REST compter exclusivement sur l'obtention de l'information nécessaire en utilisant l'approche de l'URL. REST peut utiliser quatre différents méthodes HTTP(GET, POST, PUT et DELETE) pour effectuer des tâches.

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

Avant de passer des heures à choisir entre SOAP et REST, il faut prendre en compte que certains services Web supportent l'un ou l'autre. Si vous envisagez de créer votre propre service Web, le choix du protocole peut être plus évident. Extrêmement peu de services Web, comme Amazon, prennent en charge les deux. L'objectif de votre décision est souvent centré sur lequel le service Web répond le mieux à vos besoins, plutôt que le protocole à utiliser.


 

1 - SOAP VS REST

SOAP est certainement un choix de taille pour l'accès au service Web. Il offre les avantages suivants par rapport à REST:

- Non dépendance par rapport à la langue, la plate-forme et le transfert (REST nécessite l'utilisation de HTTP)

- Fonctionne bien dans des environnements distribués (REST nécessite une communication directe point à point)

- Standardisé

- Fournit une extensibilité de pré-compilation significative sous la forme de normes WS standards

- Intégre la gestion des erreurs

- Automatisé lorsqu'il est utilisé avec des produits utilisant certains langages de programmation

En majorité, REST est plus facile à utiliser et est plus souple. Il a les avantages suivants par rapport à SOAP:

- Aucun besoin d'outils coûteux pour interagir avec le service Web

- Une courbe d'apprentissage plus petite pour les développeurs

- Efficace (SOAP utilise XML pour tous les messages, REST peut utiliser des formats de message plus petits)

- Rapide (pas de traitement étendu requis)

- Proche d'autres technologies Web dans sa philosophie de conception


 

2 - Retrouver des services web gratuits

La meilleure façon de découvrir le meilleur fonctionnement entre SOAP ou REST est d'essayer un certain nombre de services Web gratuits. Faire tourner votre propre service Web peut être un processus long, il est donc préférable d'essayer des services web déjà créés pour commencer. En outre, comme vous travaillez avec ces services Web gratuits, vous pouvez découvrir un besoin auxquels ils répondent au sein de votre entreprise. Vous permettrez donc à cette dernière un gain en temps et en coûts. Voici quelques web services à essayer:

- Free-Web-Services.com

- WebserviceX.NET

- SwaggerHub

- XMethods

Une principale préoccupation lors de l'utilisation d'un service Web gratuit est la crainte qu'il pourrait en quelque sorte endommager votre système ou votre réseau. Les services Web vous envoient généralement du texte, pas de scripts, de code ou de données binaires, ce qui diminue considérablement les risques.

Bien sûr, on peut aussi craindre que ces services Web disparaîssent du jour au lendemain. Dans la plupart des cas, ces services Web sont particuliérement stables et il est peu probable que l'un d'eux disparaîsse de sitôt. Cependant, essayez d'utiliser des services Web ayant une grande présence sur Internet. Effectuez des recherches approfondies dessus avant de commencer à l'utiliser.


 

3 - Un exemple de web service REST

Parfois, le plus simple est le meilleur. Dans cette optique, REST est aussi simple qu'il en a l'air,vous aurez juste besoin d'un URL. Ouvrez votre navigateur, quel qu'il soit et tapez http://api.geonames.org/findNearestAddressJSON?lat=40.771&lng=-73.97&username=demo dans le champ d'adresse. Appuyez sur Entrée. Vous verrez le résultat dans votre navigateur au format JSON:

Ce web service retrouve la rue et l'adresse la plus proche pour une paire lng / lat donnée (pour notre exemple les coordonnées désignent Central Park à New York : lat=40.771 lng=-73.97).

L'Url du web service est : http://api.geonames.org/findNearestAddress?

Les Paramètres sont: lat, lng, (désignant la latitude et la longitude)

Restriction: ce webservice est disponible uniquement pour les Etats-Unis.

Le Résultat: Ce web service renvoie l'adresse la plus proche de la latitude / longitude donnée, le numéro de rue par rapprochement en utilisant une interpolation de numéro de rue, à la fin d'un segment de rue.

En combinant des services Web avec votre propre code, vous pouvez créer des applications très intéressantes qui font des actions étonnantes dans un temps incroyablement court avec peu d'effort de votre part. Vous pouvez également tester votre API REST simplement en utilisant des outils comme SoapUI.


 

4 - Un exemple de web service SOAP

SOAP exige un peu plus la paramétrage, mais je pense que vous serez étonné de voir comment il est simple à utiliser. Nous allons traiter un exemple sur une application open source permettant le test de web service qui est : SOAPUI V5. Voici là où l'automatisation joue son rôle. Allez sur "file" puis cliquez sur "New SOAP Project" . Nommer votre nouveau projet et tapez l'adresse suivante dans le champ d'adresse le fichier WSDL suivant: http://www.dataaccess.com/webservicesserver/numberconversion.wso?WSDL et cliquez sur OK.Votre boîte de dialogue devrait ressembler à celui représenté ici.

Il s'agit d'un web service qui convertit un nombre en au format toutes lettres. Vous pouvez développer n'importe quelle application avec n'importe quel langage pour consommer ce web service. Il faudra appeler une fonction pour créer le client SOAP puis consommer une des méthodes des web services en envoyant les paramétres nécessaires. Nous allons tester cela avec SOAPUI.

Ci-dessous un aperçu de l'utilisation du web service pour convertir un chiffres en son format lettres. Nous allons remplir la balise ubinumb avec un nombre puis exécuter l'appel du web service. Nous avons sur la partie droite le résultat de l'appel de la méthode de conversion :

Conclusion

Certaines personnes estiment que l'un des protocoles est meilleur que l'autre, Cette affirmation reste incohérente. En effet, chaque protocole présente certains avantages des inconvénients tout aussi contraignants. Vous devez choisir entre SOAP et REST en vous basant sur le langage de programmation que vous utilisez, l'environnement dans lequel vous l'utilisez ainsi que les exigences de l'application. Parfois, SOAP est un meilleur choix et d'autres fois c'est REST qui l'est. Afin d'éviter des d'avoir des difficultés, vous aurez vraiment besoin de souligner les avantages et les inconvénients d'une solution en particulier dans votre situation.

Il y a une régle d'or qu'il faudra retenir de cet article. Ne pas tout refaire à zéro. Il est parfois étonnant de voir les entreprises dépensant beaucoup d'argent pour développer des services Web qui existent déjà (et sont plus efficaces que ceux développés par les entreprises). Il faut qu'à chaque fois que cela soit possible, rechercher des alternatives gratuites. Dans de nombreux cas, le choix du service Web détermine également votre choix de protocole à utiliser.

Actuellement, il y en a deux. Que vous choisissez entre SOAP ou REST pour votre service Web, assurez vous de tester soigneusement vos API. Ready! API dispose d'une gamme complète d'outils fonctionnels, de performance, de sécurité et de virtualisation pour tester votre API.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels