SOAP vs REST (différences)

Question

J'ai lu des articles sur les différences entre SOAP et REST en tant que protocole de communication de services Web, mais je pense que les plus grands avantages de REST par rapport à SOAP sont les suivants :

1. REST est plus dynamique, il n'est pas nécessaire de créer et de mettre à jour UDDI (Universal Description, Discovery, and Integration).

2. REST n'est pas limité au seul format XML. Les services web RESTful peuvent envoyer du texte brut/JSON/XML.

Mais SOAP est plus normalisé (ex. : sécurité).

Alors, ai-je raison sur ces points ?

Answer 1

Tout d'abord : officiellement, la question correcte serait web services + WSDL + SOAP vs REST .

Car, bien que le service web est utilisé au sens large, lorsque l'on utilise le protocole HTTP pour transférer des données. données au lieu de pages web, officiellement c'est une forme très spécifique de cette idée. Selon la définition, REST n'est pas un "service web".

En pratique, cependant, tout le monde ignore cela, alors ignorons-le aussi.

Il y a déjà des réponses techniques, alors je vais essayer de fournir quelques intuitions.

Imaginons que vous souhaitiez appeler une fonction dans un ordinateur distant, implémentée dans un autre langage de programmation (on parle souvent de appel de procédure à distance/RPC ). Supposons que cette fonction puisse être trouvée à une URL spécifique, fournie par la personne qui l'a écrite. Vous devez (en quelque sorte) lui envoyer un message et obtenir une réponse. Il y a donc deux questions principales à considérer.

• Quel est le format du message que vous devez envoyer ?
• comment le message doit-il être transmis dans les deux sens

Pour la première question, la définition officielle est WSDL . Il s'agit d'un fichier XML qui décrit, dans un format détaillé et strict, quels sont les paramètres, quels sont leurs types, leurs noms, leurs valeurs par défaut, le nom de la fonction à appeler, etc. Un exemple de WSDL montre ici que le fichier est lisible par l'homme (mais pas facilement).

Pour la deuxième question, il existe plusieurs réponses. Cependant, la seule utilisée en pratique est SOAP . Son idée principale est d'envelopper le XML précédent (le message réel) dans un autre XML (contenant des informations d'encodage et d'autres éléments utiles), et de l'envoyer via HTTP. La méthode POST du HTTP est utilisée pour envoyer le message, puisque il y a toujours un corps .

L'idée principale de cette approche est que vous faire correspondre une URL à une fonction c'est-à-dire une action . Ainsi, si vous avez une liste de clients dans un serveur, et que vous voulez en afficher/mettre à jour/supprimer un, vous devez avoir 3 URL :

• myapp/read-customer et dans le corps du message, passez l'id du client à lire.
• myapp/update-customer et dans le corps, passez l'id du client, ainsi que les nouvelles données
• myapp/delete-customer et l'identifiant dans le corps

L'approche REST voit les choses différemment. Une URL ne doit pas représenter une action, mais une chose (appelé ressource dans le jargon REST). Puisque le protocole HTTP (que nous utilisons déjà) supporte les verbes, utiliser ces verbes pour spécifier les actions à exécuter sur la chose.

Donc, avec l'approche REST, le client numéro 12 serait trouvé sur l'URL myapp/customers/12 . Pour consulter les données du client, vous tapez l'URL avec une requête GET. Pour les supprimer, le même URL, avec un verbe DELETE. Pour le mettre à jour, encore une fois, le même URL avec un verbe POST, et le nouveau contenu dans le corps de la requête.

Pour plus de détails sur les exigences qu'un service doit remplir pour être considéré comme véritablement RESTful, voir le site Web de la Commission européenne. Modèle de maturité de Richardson . L'article donne des exemples et, surtout, explique pourquoi un (soi-disant) service SOAP est un service REST de niveau 0 (bien que le niveau 0 signifie une faible conformité à ce modèle, il n'est pas choquant et reste utile dans de nombreux cas).

Answer 2

Parmi beaucoup d'autres déjà abordés dans les nombreuses réponses, je soulignerais que SOAP permet de définir un contrat, le WSDL, qui définit les opérations supportées, les types complexes, etc. SOAP est orienté vers les opérations, mais REST est orienté vers les ressources. Personnellement, je choisirais SOAP pour les interfaces complexes entre les applications internes de l'entreprise, et REST pour les interfaces publiques, plus simples et sans état avec le monde extérieur.

Answer 3

Ajout pour :

++ Une erreur souvent commise lorsqu'on aborde REST est de penser qu'il s'agit de "services Web avec des URL", c'est-à-dire de considérer REST comme un autre mécanisme d'appel de procédure à distance (RPC), comme SOAP, mais invoqué par le biais d'URL HTTP simples et sans les lourds espaces de noms XML de SOAP.

++ Au contraire, REST a peu à voir avec RPC. Alors que RPC est orienté services et se concentre sur les actions et les verbes, REST est orienté ressources et met l'accent sur les choses et les noms qui composent une application.

Answer 4

Beaucoup de ces réponses ont complètement oublié de mentionner les contrôles hypermédia (HATEOAS) qui sont tout à fait fondamentaux pour REST. Quelques autres l'ont abordé, mais ne l'ont pas vraiment bien expliqué.

Cet article devrait expliquer la différence entre les concepts, sans entrer dans les détails des caractéristiques spécifiques de SOAP.

Answer 5

Qu'est-ce que REST ?

REST est l'abréviation de "representational state transfer" (transfert d'état représentationnel). Il s'agit en fait d'un style architectural pour la création d'API Web qui traite tout (données ou fonctionnalités) comme un recours. Il prévoit l'exposition de ressources par le biais d'URI et la réponse dans plusieurs formats, ainsi que le transfert de l'état des ressources de manière apatride. Ici, je parle de deux choses :

1. Manière apatride : Fourni par HTTP.
2. Transfert représentationnel de l'état : Par exemple, si nous ajoutons un employé. . dans notre système, il est dans l'état POST de HTTP, après cela il serait dans l'état GET de HTTP, PUT et DELETE de même.

REST peut utiliser les services web SOAP car il s'agit d'un concept qui peut utiliser n'importe quel protocole comme HTTP, SOAP. SOAP utilise des interfaces de services pour exposer la logique commerciale. REST utilise l'URI pour exposer la logique métier.

Le REPOS n'est pas le REPOS sans HATÉOAS. Cela signifie qu'un client ne connaît que l'URI du point d'entrée et que les ressources sont censées renvoyer des liens que le client doit suivre. Ces générateurs de documentation fantaisistes qui donnent des modèles d'URI pour tout ce que vous pouvez faire dans une API REST passent complètement à côté de l'essentiel. Non seulement ils documentent quelque chose qui est censé suivre la norme, mais en plus, ils couplent le client à un moment particulier de l'évolution de l'API, et toute modification de l'API doit être documentée et appliquée, sous peine de rupture.

HATEOAS, abréviation de Hypermedia As The Engine Of Application State, est une contrainte de l'architecture d'application REST qui la distingue de la plupart des autres architectures d'application réseau. Le principe est qu'un client interagit avec une application réseau entièrement par le biais d'hypermédia fourni dynamiquement par les serveurs d'application. Un client REST n'a besoin d'aucune connaissance préalable sur la manière d'interagir avec une application ou un serveur particulier, si ce n'est une compréhension générique de l'hypermédia. En revanche, dans certaines architectures orientées services (SOA), les clients et les serveurs interagissent par le biais d'une interface fixe partagée par la documentation ou un langage de description d'interface (IDL).

Référence 1 Référence 2