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

Malheureusement, il existe de nombreuses informations et idées fausses sur REST. Non seulement votre question et le réponse de @cmd reflète ceux-ci, mais la plupart des questions et réponses liées au sujet sur Stack Overflow.

SOAP et REST ne peuvent pas être comparés directement, car le premier est un protocole (ou du moins tente de l'être) et le second est un style architectural. C'est probablement l'une des sources de confusion à ce sujet, car les gens ont tendance à appeler REST toute API HTTP qui n'est pas SOAP.

En poussant un peu les choses et en essayant d'établir une comparaison, la principale différence entre SOAP et REST est le degré de couplage entre les implémentations client et serveur. Un client SOAP fonctionne comme une application de bureau personnalisée, étroitement couplée au serveur. Il existe un contrat rigide entre le client et le serveur, et tout est censé se briser si l'un des deux côtés change quoi que ce soit. Vous avez besoin de mises à jour constantes après tout changement, mais il est plus facile de vérifier si le contrat est respecté.

Un client REST ressemble davantage à un navigateur. Il s'agit d'un client générique qui sait comment utiliser un protocole et des méthodes standardisées, et une application doit s'y adapter. Vous ne violez pas les normes du protocole en créant des méthodes supplémentaires, vous vous appuyez sur les méthodes standard et créez les actions avec elles sur votre type de média. Si cela est fait correctement, il y a moins de couplage et les changements peuvent être traités avec plus de souplesse. Un client est censé entrer dans un service REST sans aucune connaissance de l'API, à l'exception du point d'entrée et du type de média. Dans SOAP, le client doit connaître au préalable tout ce qu'il va utiliser, sinon il ne commencera même pas l'interaction. En outre, un client REST peut être étendu par du code à la demande fourni par le serveur lui-même, l'exemple classique étant le code JavaScript utilisé pour piloter l'interaction avec un autre service du côté client.

Je pense que ce sont les points cruciaux pour comprendre ce qu'est REST, et en quoi il diffère de SOAP :

• REST est indépendant du protocole. Il n'est pas couplé à HTTP. Tout comme vous pouvez suivre un lien ftp sur un site web, une application REST peut utiliser n'importe quel protocole pour lequel il existe un schéma URI standardisé.

• REST n'est pas une mise en correspondance de CRUD avec des méthodes HTTP. Lire este pour une explication détaillée à ce sujet.

• REST est aussi normalisé que les parties que vous utilisez. La sécurité et l'authentification dans HTTP sont normalisées, c'est donc ce que vous utilisez lorsque vous faites REST sur HTTP.

• REST n'est pas REST sans hypermédia y HATEOAS . 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.

• REST est le style architectural du web lui-même. Lorsque vous entrez dans Stack Overflow, vous savez ce qu'est un utilisateur, une question et une réponse, vous connaissez les types de médias et le site Web vous fournit les liens vers ceux-ci. Une API REST doit faire de même. Si nous concevions le web de la manière dont les gens pensent que REST devrait être fait, au lieu d'avoir une page d'accueil avec des liens vers les questions et les réponses, nous aurions une documentation statique expliquant que pour voir une question, vous devez prendre l'URI stackoverflow.com/questions/<id> remplacez id par Question.id et collez cela dans votre navigateur. C'est absurde, mais c'est ce que beaucoup de gens pensent que REST est.

On n'insistera jamais assez sur ce dernier point. Si vos clients créent des URI à partir de modèles dans la documentation et n'obtiennent pas de liens dans les représentations des ressources, ce n'est pas REST. Roy Fielding, l'auteur de REST, l'a clairement indiqué dans cet article de blog : Les API REST doivent être axées sur l'hypertexte. .

En gardant à l'esprit ce qui précède, vous vous rendrez compte que si REST n'est pas limité à XML, pour le faire correctement avec tout autre format, vous devrez concevoir et normaliser un certain format pour vos liens. Les hyperliens sont standardisés en XML, mais pas en JSON. Il existe des projets de normes pour JSON, par exemple HAL .

Enfin, REST ne convient pas à tout le monde, et la preuve en est que la plupart des gens résolvent très bien leurs problèmes avec les API HTTP qu'ils appellent par erreur REST et ne s'aventurent jamais au-delà. REST est parfois difficile à mettre en œuvre, surtout au début, mais cela se paye au fil du temps avec une évolution plus facile du côté serveur, et la résilience du client aux changements. Si vous avez besoin de faire quelque chose rapidement et facilement, ne vous souciez pas d'utiliser REST correctement. Ce n'est probablement pas ce que vous recherchez. Si vous avez besoin de quelque chose qui devra rester en ligne pendant des années, voire des décennies, alors REST est fait pour vous.

Answer 2

REST vs SOAP es pas la bonne question à poser.

REST contrairement à SOAP es pas un protocole.

REST est un style architectural et un diseño pour les architectures logicielles en réseau.

REST Les concepts sont appelés ressources. La représentation d'une ressource doit être sans état. Elle est représentée par un certain type de média. Voici quelques exemples de types de médias XML , JSON y RDF . Les ressources sont manipulées par les composants. Les composants demandent et manipulent les ressources via une interface uniforme standard. Dans le cas de HTTP, cette interface est constituée d'opérations HTTP standard, par ex. GET , PUT , POST , DELETE .

La question de @Abdulaziz met en lumière le fait que REST y HTTP sont souvent utilisés en tandem. Cela est principalement dû à la simplicité du protocole HTTP et à sa correspondance très naturelle avec les principes RESTful.

Principes fondamentaux de REST

Communication client-serveur

Les architectures client-serveur présentent une séparation très nette des préoccupations. Toutes les applications construites dans le style RESTful doivent également être client-serveur en principe.

Apatride

Chaque demande du client au serveur nécessite que son état soit entièrement représenté. Le serveur doit être capable de comprendre complètement la demande du client sans utiliser le contexte du serveur ou l'état de la session du serveur. Il s'ensuit que tout l'état doit être conservé sur le client.

Cachable

Des contraintes de mise en cache peuvent être utilisées, permettant ainsi aux données de réponse d'être marquées comme pouvant être mises en cache ou non. Toute donnée marquée comme pouvant être mise en cache peut être réutilisée comme réponse à la même demande ultérieure.

Interface uniforme

Tous les composants doivent interagir par le biais d'une interface unique et uniforme. Comme toutes les interactions entre composants se font via cette interface, l'interaction avec différents services est très simple. L'interface est la même ! Cela signifie également que les changements d'implémentation peuvent être effectués de manière isolée. De telles modifications n'affecteront pas l'interaction fondamentale des composants, car l'interface uniforme reste toujours inchangée. L'inconvénient est que vous êtes coincé avec l'interface. Si un service spécifique pouvait être optimisé en modifiant l'interface, vous n'avez pas de chance car REST l'interdit. Le bon côté des choses, c'est que REST est optimisé pour le web, d'où l'incroyable popularité de REST sur HTTP !

Les concepts ci-dessus représentent les caractéristiques de définition de REST et différencient l'architecture REST d'autres architectures comme les services web. Il est utile de noter qu'un service REST est un service web, mais qu'un service web n'est pas nécessairement un service REST.

Voir ce blog poste en Principes de conception REST pour plus de détails sur REST et les balles mentionnées ci-dessus.

EDITAR: mettre à jour le contenu en fonction des commentaires

Answer 3

SOAP ( Protocole d'accès simple aux objets ) et REST ( Transfert d'état de représentation ) les deux sont magnifiques à leur manière. Je ne les compare donc pas. Au lieu de cela, j'essaie de dépeindre l'image, quand je préfère utiliser REST et quand SOAP.

Qu'est-ce que la charge utile ?

Lorsque des données sont envoyées sur Internet, chaque unité transmise comprend à la fois des informations d'en-tête et les données réelles envoyées. L'en-tête identifie la source et la destination du paquet, tandis que les données réelles sont appelées "données utiles". . En général, la charge utile est constituée des données transportées au nom d'une application et des données reçues par le système de destination.

Maintenant, par exemple, je dois envoyer un Télégramme et nous savons tous que le coût du télégramme dépendra de certains mots.

Alors dites-moi, parmi les deux messages mentionnés ci-dessous, lequel est le moins cher à envoyer ?

<name>Arin</name>

o

"name": "Arin"

Je sais que votre réponse sera la seconde, bien que les deux représentent le même message, la seconde est moins chère en termes de coût.

C'est ce que j'essaie de dire, l'envoi de données sur le réseau au format JSON est moins coûteux que l'envoi au format XML en ce qui concerne la charge utile .

Voici le premier avantage ou les premiers avantages de REST par rapport à SOAP . SOAP ne prend en charge que le XML, mais REST prend en charge différents formats comme le texte, JSON, XML, etc. Et nous savons déjà que si nous utilisons Json, nous serons certainement dans une meilleure position en ce qui concerne la charge utile.

Aujourd'hui, SOAP ne supporte que le XML, mais elle a aussi ses avantages.

Vraiment ! Comment ?

SOAP s'appuie sur XML de trois manières Enveloppe - qui définit le contenu du message et la manière de le traiter.

Un ensemble de règles d'encodage pour les types de données, et enfin la disposition des appels de procédure et des réponses rassemblées.

Cette enveloppe est envoyée via un transport (HTTP/HTTPS), et un RPC (Remote Procedure Call) est exécuté, et l'enveloppe est renvoyée avec des informations dans un document au format XML.

Le point important est que l'un des avantages de SOAP est l'utilisation de la "transport "générique mais REST utilise HTTP/HTTPS . SOAP peut utiliser presque n'importe quel transport pour envoyer la demande, mais REST ne le peut pas. Nous avons donc ici un avantage à utiliser SOAP.

Comme je l'ai déjà mentionné dans le paragraphe précédent "REST utilise HTTP/HTTPS" alors approfondissez un peu plus ces mots.

Lorsque nous parlons de REST sur HTTP, toutes les mesures de sécurité appliquées à HTTP sont héritées, ce qui est connu sous le nom de la sécurité au niveau du transport et il ne sécurise les messages que pendant il est à l'intérieur du fil mais une fois que vous l'avez livré de l'autre côté, vous ne savez pas combien d'étapes il devra franchir avant d'atteindre le point réel où les données seront traitées. Et bien sûr, toutes ces étapes pourraient utiliser autre chose que HTTP. Donc le repos n'est pas complètement sûr, n'est-ce pas ?

Mais SOAP supporte SSL tout comme REST en plus il supporte également WS-Security qui ajoute des fonctions de sécurité d'entreprise. WS-Security offre une protection contre les de la création du message à sa consommation . Ainsi, pour la sécurité au niveau du transport, toute faille que nous avons trouvée peut être évitée en utilisant WS-Security.

En dehors de cela, comme REST est limité par son protocole HTTP. La prise en charge des transactions n'est donc pas conforme à la norme ACID et ne permet pas d'effectuer un commit en deux phases sur des ressources distribuées transnationales.

Mais SOAP a un support complet pour les deux Gestion des transactions basée sur ACID pour les transactions à court terme et la gestion des transactions basée sur la rémunération pour les transactions à long terme. Il prend également en charge engagement en deux phases sur des ressources distribuées .

Je ne tire aucune conclusion, mais je préférerai un service web basé sur SOAP si la sécurité, les transactions, etc. sont les principales préoccupations.

Voici le "The Java EE 6 Tutorial" où ils ont dit Une conception RESTful peut être appropriée lorsque les conditions suivantes sont réunies . Jetez un coup d'œil.

J'espère que vous avez apprécié ma réponse.

Answer 4

REST ( RE présentation S tate T ransfer)
RE présentation S L'état d'un objet est T ransferred est REST, c'est-à-dire que nous n'envoyons pas d'objet, mais l'état de l'objet. REST est un style architectural. Il ne définit pas autant de normes que SOAP. REST permet d'exposer des API publiques (par exemple, l'API de Facebook, l'API de Google Maps) sur Internet afin de gérer les opérations CRUD sur les données. REST se concentre sur l'accès à des ressources nommées via une interface unique et cohérente.

SOAP ( S imple O bjet A ccessibilité P rotocol)
SOAP apporte son propre protocole et se concentre sur l'exposition d'éléments de logique applicative (et non de données) en tant que services. SOAP expose des opérations. SOAP est axé sur l'accès à des opérations nommées, chaque opération mettant en œuvre une certaine logique commerciale. Bien que SOAP soit communément appelé services web C'est un terme mal choisi. SOAP a très peu, voire rien, à voir avec le Web. REST fournit de véritables Services web basé sur les URI et HTTP.

Pourquoi REST ?

• Comme REST utilise le protocole HTTP standard, il est beaucoup plus simple à tous égards.
• REST est plus facile à mettre en œuvre et nécessite moins de bande passante et de ressources.
• REST autorise de nombreux formats de données différents, alors que SOAP n'autorise que le XML.
• REST permet une meilleure prise en charge des clients navigateurs grâce à sa prise en charge de JSON.
• REST offre de meilleures performances et une meilleure évolutivité. Les lectures REST peuvent être mises en cache, celles basées sur SOAP ne le peuvent pas.
• Si la sécurité n'est pas une préoccupation majeure et que nous avons des ressources limitées. Ou si nous voulons créer une API qui sera facilement utilisée par d'autres développeurs publiquement, alors nous devrions opter pour REST.
• Si nous avons besoin d'opérations CRUD apatrides, il faut opter pour REST.
• REST est couramment utilisé dans les médias sociaux, les discussions en ligne, les services mobiles et les API publiques comme Google Maps.
• Les services RESTful renvoient différents types de médias pour la même ressource, en fonction du paramètre "Accept" de l'en-tête de la requête, comme suit application/xml o application/json pour POST et /user/1234.json ou GET /user/1234.xml pour GET.
• Les services REST sont destinés à être appelés par l'application côté client et non par l'utilisateur final directement.
• ST dans REST provient de S tate T ransfert. Vous transférez l'état au lieu de le faire stocker par le serveur, ce qui rend les services REST évolutifs.

Pourquoi SOAP ?

• SOAP n'est pas très facile à mettre en œuvre et nécessite davantage de bande passante et de ressources.
• Les demandes de messages SOAP sont traitées plus lentement que les demandes REST et n'utilisent pas le mécanisme de mise en cache.
• WS-Security : Si SOAP prend en charge SSL (tout comme REST), il prend également en charge WS-Security, qui ajoute certaines fonctions de sécurité d'entreprise.
• WS-AtomicTransaction : Si vous avez besoin de transactions ACID sur un service, vous allez avoir besoin de SOAP.
• WS-ReliableMessaging : Si votre application nécessite un traitement asynchrone et un niveau garanti de fiabilité et de sécurité. Rest ne dispose pas d'un système de messagerie standard et s'attend à ce que les clients gèrent les échecs de communication en réessayant.
• Si la sécurité est une préoccupation majeure et que les ressources ne sont pas limitées, nous devrions utiliser les services Web SOAP. Par exemple, si nous créons un service web pour des passerelles de paiement, des travaux financiers et de télécommunication, nous devrions utiliser SOAP car une sécurité élevée est nécessaire.

source1
source2

Answer 5

À mon avis, vous ne pouvez pas comparer SOAP et REST, qui sont deux choses différentes.

SOAP est un protocole et REST est un modèle d'architecture logicielle. Il y a beaucoup d'idées fausses sur l'internet pour SOAP et REST .

SOAP définit un format de message basé sur XML que les applications de services Web utilisent pour communiquer entre elles sur Internet. Pour ce faire, les applications doivent avoir une connaissance préalable du contrat de message, des types de données, etc.

REST représente l'état (en tant que ressources) d'un serveur à partir d'une URL. Il est sans état et les clients ne doivent pas avoir de connaissances préalables pour interagir avec le serveur au-delà de la compréhension de l'hypermédia.