SOAP vs REST (différences)
J'ai lu des articles sur les différences entre SOAP et REST en tant que protocole de communication de service Web, mais je pense que le principal avantage de REST par rapport à SOAP sont:
REST est plus dynamique, pas besoin de créer et de mettre à jour UDDI (Universal Description, Discovery et Integration).
REST n'est pas limité au seul format XML. Les services Web RESTful peuvent envoyer du texte brut/JSON/XML.
Mais SOAP est plus standardisé (par exemple: sécurité).
Alors, est-ce que j'ai raison sur ces points?
Malheureusement, il y a beaucoup de désinformation et d'idées fausses sur REST. Non seulement votre question et le réponse de @cmd reflètent ceux-ci, mais la plupart des questions et réponses portent sur le sujet traité dans 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 autour de cela, 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 client et serveur, et tout devrait casser si l'une ou l'autre des parties change quelque chose. 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. C'est un client générique qui sait comment utiliser un protocole et des méthodes normalisées, et une application doit s'y adapter. Vous ne violez pas les normes de protocole en créant des méthodes supplémentaires, vous exploitez les méthodes standard et créez les actions avec celles-ci sur votre type de support. Si cela est bien fait, il y a moins de couplage et les changements peuvent être traités de manière plus élégante. 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 support. Sous SOAP, le client a besoin de connaissances préalables sur tout ce qu’il utilisera, sinon il ne commencera même pas l’interaction. De plus, un client REST peut être étendu par le code à la demande fourni par le serveur lui-même, l'exemple classique étant le code JavaScript utilisé pour gérer l'interaction avec un autre service côté client.
Je pense que ce sont les points cruciaux pour comprendre en quoi consiste REST et en quoi cela diffère de SOAP:
REST est indépendant du protocole. Ce n'est pas couplé à HTTP. Un peu comme si vous pouviez 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 normalisé.
REST n'est pas un mappage de CRUD sur des méthodes HTTP. Lire this répondre pour une explication détaillée à ce sujet.
REST est aussi standardisé que les pièces 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 et HATEOAS . Cela signifie qu'un client ne connaît que l'URI du point d'entrée et que les ressources sont supposées renvoyer les liens que le client doit suivre. Ces générateurs de documentation sophistiqués qui donnent des modèles d'URI pour tout ce que vous pouvez faire dans une API REST ne passent à rien. Ils documentent non seulement quelque chose qui est censé suivre la norme, mais lorsque vous le faites, vous couplez le client à un moment donné de l'évolution de l'API, et toute modification apportée à l'API doit être documentée et appliquée. ou ça va casser.
REST est le style architectural du Web lui-même. Lorsque vous entrez Stack Overflow, vous savez ce qu’est un utilisateur, une question et une réponse, vous connaissez les types de média et le site Web vous en fournit les liens. Une API REST doit faire la même chose. Si nous concevions le Web de la façon dont les gens pensent que REST devrait être fait, au lieu d'avoir une page d'accueil avec des liens vers Questions et réponses, nous aurions une documentation statique expliquant que pour afficher une question, vous: devez prendre l'URI
stackoverflow.com/questions/<id>, remplacer id par Question.id et collez-le dans votre navigateur. C'est un non-sens, mais c'est ce que beaucoup de gens pensent que REST est.
Ce dernier point ne saurait être assez souligné. Si vos clients construisent des URI à partir de modèles dans la documentation et n'obtiennent pas de liens dans les représentations de ressources, ce n'est pas REST. Roy Fielding, l'auteur de REST, a expliqué clairement dans cet article de blog: les API REST doivent être pilotées par hypertexte .
Compte tenu de ce qui précède, vous vous rendrez compte que, bien que REST puisse ne pas être limité à XML, pour le faire correctement avec tout autre format, vous devrez concevoir et normaliser un format quelconque pour vos liens. Les hyperliens sont standard en XML, mais pas en JSON. Il existe des projets de normes pour JSON, tels que HAL .
Enfin, REST ne convient pas à tout le monde, et la plupart des gens résolvent très bien leurs problèmes avec les API HTTP appelées à tort REST et ne s'aventurent jamais plus loin. REST est parfois difficile à faire, surtout au début, mais cela rapporte dans le temps, car il est plus facile d'évoluer côté serveur et de résister aux changements du client. Si vous souhaitez que quelque chose soit fait rapidement et facilement, ne vous embêtez pas pour que REST soit correct. 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.
REST vs SOAP est pas la bonne question à poser.
REST, contrairement à SOAP est pas un protocole.
REST est un style architectural et une conception pour les architectures logicielles basées sur le réseau.
Les concepts REST sont appelés ressources. Une représentation d'une ressource doit être sans état. Il est représenté via un type de média. Quelques exemples de types de supports incluent XML, JSON et RDF. Les ressources sont manipulées par des composants. Les composants demandent et manipulent des ressources via une interface uniforme standard. Dans le cas de HTTP, cette interface consiste en des opérations HTTP standard, par exemple. GET, PUT, POST, DELETE.
La question de @ Abdulaziz met en lumière le fait que REST et HTTP sont souvent utilisés en tandem. Ceci est principalement dû à la simplicité de HTTP et à sa correspondance très naturelle avec les principes RESTful.
Principes fondamentaux REST
Communication client-serveur
Les architectures client-serveur ont une séparation très distincte des préoccupations. Toutes les applications construites dans le style RESTful doivent également être en principe client-serveur.
Sans état
Chaque demande 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 aucun contexte de serveur ou état de session de serveur. Il s'ensuit que tout état doit être conservé sur le client.
Cacheable
Des contraintes de 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 via une seule interface uniforme. Étant donné que toutes les interactions entre composants se produisent via cette interface, l’interaction avec différents services est très simple. L'interface est la même! Cela signifie également que les modifications d'implémentation peuvent être effectuées de manière isolée. De tels changements n’affecteront pas l’interaction fondamentale des composants car l’interface uniforme est toujours inchangée. Un inconvénient est que vous êtes coincé avec l'interface. Si une optimisation peut être fournie à un service spécifique en modifiant l'interface, vous n'avez aucune chance, car REST l'interdit. Cependant, REST est optimisé pour le Web, d'où la popularité incroyable de REST sur HTTP!
Les concepts ci-dessus représentent les caractéristiques de définition de REST et différencient l'architecture REST des autres architectures telles que 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 post on Principes de conception REST pour plus de détails sur RESTE et les puces mentionnées ci-dessus.
EDIT: mettre à jour le contenu en fonction des commentaires
SOAP ( Protocole d'accès aux objets simples ) et REST ( Transfert d'état de représentation ) sont tous deux magnifiques. . Donc je ne les compare pas. Au lieu de cela, j'essaie de représenter l'image lorsque j'ai préféré utiliser REST et lorsque 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éellement 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, les données utiles sont les données transportées pour le compte d'une application et les données reçues par le système de destination.
Maintenant, par exemple, je dois envoyer un Telegram et nous savons tous que le coût du télégramme dépendra de quelques mots.
Alors, dites-moi parmi les réponses mentionnées ci-dessous ces deux messages, lequel est le moins cher à envoyer?
<name>Arin</name>
ou
"name": "Arin"
Je sais que votre réponse sera la deuxième, bien que les deux représentent le même message, le deuxième message étant meilleur marché.
J'essaie donc de dire que envoyer des données sur le réseau au format JSON revient moins cher que de les envoyer au format XML en ce qui concerne la charge utile .
Voici le ou les premiers avantages de REST sur SOAP . SOAP ne prend en charge que le XML, mais REST prend en charge différents formats tels que texte, JSON, XML, etc. .
Maintenant, SOAP supporte le seul XML, mais il a aussi ses avantages.
Vraiment! Comment?
SOAP repose sur XML de trois manières différentes. Enveloppe: elle définit le contenu du message et son traitement.
Un ensemble de règles de codage pour les types de données et, enfin, la présentation des appels de procédure et des réponses recueillies.
Cette enveloppe est envoyée via un transport (HTTP/HTTPS), un appel de procédure distante (RPC) est exécuté et l'enveloppe est renvoyée avec les informations dans un document au format XML.
Le point important est que un des avantages de SOAP est l’utilisation du transport "générique" mais REST utilise HTTP/HTTPS . SOAP peut utiliser presque tous les moyens de transport pour envoyer la demande, mais REST ne le peut pas. Nous avons donc un avantage à utiliser SOAP.
Comme je l'ai déjà mentionné dans le paragraphe ci-dessus “REST utilise HTTP/HTTPS” , approfondissez donc un peu ces mots.
Lorsque nous parlons de REST sur HTTP, toutes les mesures de sécurité appliquées par HTTP sont héritées. Cette opération s'appelle sécurité du niveau de transport et ne sécurise les messages que si c'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 quelque chose de différent de HTTP. Donc, Rest n'est pas complètement sûr, non?
Mais SOAP prend en charge SSL comme REST en plus , il prend également en charge WS-Security ce qui ajoute des fonctionnalités de sécurité d'entreprise. WS-Security offre une protection de la création du message à sa consommation . Donc, pour la sécurité au niveau du transport, quelle que soit la faille que nous ayons trouvée, il est possible d’éviter l’utilisation de WS-Security.
En dehors de cela, comme REST est limité par son protocole HTTP , son support de transaction n’est donc pas conforme à ACID ni ne peut fournir une validation en deux phases sur des ressources transnationales distribuées.
Mais SOAP prend en charge à la fois la gestion des transactions basée sur ACID pour les transactions de courte durée et la gestion des transactions basée sur la compensation pour les transactions de longue durée. Il prend également en charge validation en deux phases sur des ressources distribuées .
Je ne tire aucune conclusion, mais je préférerai un service Web basé sur SOAP, tandis que la sécurité, les transactions, etc. sont les principales préoccupations.
Voici le "Le Java EE 6 Tutorial" où ils ont dit ne conception RESTful peut être appropriée lorsque les conditions suivantes sont remplies . Regarde.
J'espère que vous avez apprécié la lecture de ma réponse.
RESTE (RE présentation S tate T transfert)
RE présentation S état de un objet est T transféré est REST c'est-à-dire que nous n'envoyons pas Object, nous envoyons l'état d'Object. REST est un style architectural. Il ne définit pas autant de normes comme SOAP. REST sert à exposer des API publiques (API Facebook, Google Maps) sur Internet pour gérer les opérations CRUD sur les données. REST se concentre sur l'accès aux ressources nommées via une interface cohérente unique.
SOAP (S imple O bject A cces P rotocol)
SOAP apporte son propre protocole et se concentre sur la présentation d'éléments de logique applicative (et non de données) en tant que services. SOAP expose les opérations. SOAP est axé sur l'accès aux opérations nommées, chaque opération implémentant une logique métier. Bien que SOAP soit communément appelé services Web , il n’est pas approprié. SOAP a très peu, voire rien, à voir avec le Web. REST fournit de vrais services Web basés sur les URI et HTTP.
Pourquoi REST?
- Puisque REST utilise le protocole HTTP standard, il est beaucoup plus simple à chaque fois.
- REST est plus simple à mettre en œuvre et nécessite moins de bande passante et de ressources.
- REST autorise de nombreux formats de données, où SOAP autorise uniquement le format XML.
- REST permet une meilleure prise en charge des clients de navigation 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, les lectures basées sur SOAP ne peuvent pas être mises en cache.
- Si la sécurité n’est pas une préoccupation majeure et que nos ressources sont limitées. Ou nous voulons créer une API qui sera facilement utilisée publiquement par d'autres développeurs, alors nous devrions utiliser REST.
- Si nous avons besoin d'opérations CRUD sans état, utilisez REST.
- REST est couramment utilisé dans les médias sociaux, les discussions en ligne, les services mobiles et les API publiques telles que Google Maps.
- Le service RESTful renvoie différents MediaTypes pour la même ressource, en fonction du paramètre d'en-tête de demande "Accepter" sous la forme _
application/xml_ ou _application/json_ pour POST et _/user/1234.json_ ou GET _/user/1234.xml_ oublier. - Les services REST doivent être appelés par l'application côté client et non par l'utilisateur final directement.
- ST dans REST provient de S tate T transfert. Vous transférez l'état autour au lieu de le stocker sur le serveur, ce qui rend les services REST évolutifs.
Pourquoi SOAP?
- SOAP n'est pas très facile à mettre en œuvre et nécessite plus de bande passante et de ressources.
- La demande de message SOAP est traitée plus lentement que REST et n'utilise pas de mécanisme de mise en cache Web.
- WS-Security: Bien que SOAP prenne en charge SSL (tout comme REST), il prend également en charge WS-Security, qui ajoute des fonctionnalités de sécurité d'entreprise.
- WS-AtomicTransaction: Besoin de transactions ACID sur un service, vous aurez besoin de SOAP.
- WS-ReliableMessaging: Si votre application nécessite un traitement asynchrone et un niveau de fiabilité et de sécurité garanti. Rest n'a pas de système de messagerie standard et attend des clients qu'ils gèrent les échecs de communication en les réessayant.
- Si la sécurité est une préoccupation majeure et que les ressources ne sont pas limitées, nous devrions utiliser SOAP services Web. Comme si nous créons un service Web pour les passerelles de paiement, le travail financier et les télécommunications, nous devrions utiliser SOAP car ici, une sécurité élevée est nécessaire.
Différence entre le repos et le savon
SOAP
- SOAP est un protocole.
- SOAP signifie Simple Object Access Protocol.
- SOAP ne peut pas utiliser REST car il s'agit d'un protocole.
- SOAP utilise des interfaces de services pour exposer la logique métier.
- SOAP définit les normes à suivre strictement.
- SOAP nécessite plus de bande passante et de ressources que REST.
- SOAP définit sa propre sécurité.
- SOAP autorise uniquement le format de données XML.
- SOAP est moins préféré que REST.
RESTE
- REST est un style architectural.
- REST est synonyme de Representational State Transfer.
- REST peut utiliser les services Web SOAP, car il s'agit d'un concept et peut utiliser n'importe quel protocole tel que HTTP, SOAP.
- REST utilise l'URI pour exposer la logique métier.
- REST ne définit pas trop de normes comme SOAP.
- REST nécessite moins de bande passante et de ressources que SOAP.
- Les services Web RESTful héritent des mesures de sécurité du transport sous-jacent.
- REST autorise différents formats de données tels que le texte brut, HTML, XML, JSON, etc.
- REST plus préféré que SOAP.
Pour plus de détails s'il vous plaît voir ici
IMHO vous ne pouvez pas comparer SOAP et REST où ce sont deux choses différentes.
SOAP est un protocole et RESTE est une architecture logicielle modèle. Il existe de nombreuses idées fausses sur Internet pour SOAP vs REST .
SOAP définit le format de message basé sur XML que les applications utilisant des services Web utilisent pour se communiquer via 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 la connaissance préalable pour interagir avec le serveur au-delà la compréhension de l'hypermédia.
Parmi beaucoup d’autres déjà couverts dans les nombreuses réponses, je voudrais souligner que SOAP permet de définir un contrat, le WSDL, qui définit les opérations prises en charge, les types complexes, etc. SOAP est orienté aux opérations, mais REST est orienté sur les ressources. Personnellement, je choisirais SOAP pour les interfaces complexes entre les applications d'entreprise internes et REST pour les interfaces publiques, plus simples et sans état avec le monde extérieur.
Tout d'abord: officiellement, la bonne question serait
web services + WSDL + SOAPvsREST.Parce que, bien que le service Web , soit utilisé au sens large, lors de l’utilisation du protocole HTTP pour transférer des 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".
Dans la pratique cependant, tout le monde l'ignore, alors ignorons-le aussi
Il y a déjà des réponses techniques, je vais donc essayer de fournir une certaine intuition.
Supposons que vous souhaitiez appeler une fonction dans un ordinateur distant, implémentée dans un autre langage de programmation (elle est souvent appelée appel de procédure distante/RPC ). Supposons que cette fonction puisse être trouvée sur 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. Donc, il y a deux questions principales à considérer.
- quel est le format du message que vous devriez envoyer
- comment le message devrait-il être transporté
Pour la première question, la définition officielle est WSDL . Ceci est un fichier XML qui décrit, dans un format détaillé et strict, quels sont les paramètres, quels sont leurs types, noms, valeurs par défaut, nom de la fonction à appeler, etc. Exemple de WSDL montre ici que le fichier est lisible par l’homme (mais pas facilement).
Pour la deuxième question, il existe différentes réponses. Cependant, le seul utilisé en pratique est SOAP . Son idée principale est: envelopper le XML précédent (le message lui-même) dans un autre XML (contenant des informations de codage et d'autres informations utiles) et l'envoyer via HTTP. La méthode POST de HTTP est utilisée pour envoyer le message, car , il y a toujours un corps .
L’idée principale de cette approche est que vous mappez une URL sur une fonction , c’est-à-dire, sur une action . Donc, si vous avez une liste de clients sur un serveur et que vous voulez voir/mettre à jour/supprimer un, vous devez avoir 3 URL:
myapp/read-customeret dans le corps du message, passez l'identifiant du client à lire.myapp/update-customeret dans le corps, passez l'identifiant du client, ainsi que les nouvelles donnéesmyapp/delete-customeret 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ée ) ressource dans le REST jargon). Puisque le protocole HTTP (que nous utilisons déjà) supporte les verbes, utilise ces verbes pour spécifier les actions à effectuer sur la chose.
Ainsi, avec l'approche REST, le numéro de client 12 se trouve sur l'URL myapp/customers/12. Pour afficher les données du client, vous frappez l'URL avec une demande GET. Pour le supprimer, la même URL , avec un verbe DELETE. Pour le mettre à jour, à nouveau, la même URL avec un verbe POST et le nouveau contenu dans le corps de la demande.
Pour plus de détails sur les exigences qu'un service doit remplir pour être considéré comme vraiment RESTful, voir le modèle de Richardson à maturité . L'article donne des exemples et, plus important encore, explique pourquoi un service (aussi appelé) SOAP est un service de niveau 0 REST (bien que le niveau 0 signifie une faible conformité Ce modèle n’est pas offensant et reste utile dans de nombreux cas).
Ajout pour:
++ Une erreur souvent commise à l'approche de REST est de le considérer comme "des services Web avec des URL" - de penser à REST comme un autre mécanisme d'appel de procédure distante (RPC), comme SOAP, mais appelé via des URL HTTP simples et sans les espaces de noms XML lourds de SOAP.
++ Au contraire, REST a peu à voir avec RPC. Alors que RPC est orienté service et axé sur les actions et les verbes, REST est orienté ressources, en mettant l'accent sur les éléments et les noms qui constituent une application.
Beaucoup de ces réponses ont complètement oublié de mentionner les contrôles hypermédia (HATEOAS), ce qui est fondamental pour REST. Quelques autres ont abordé le sujet, mais ne l'ont pas vraiment expliqué.
Cet article devrait expliquer la différence entre les concepts, sans entrer dans les mauvaises herbes sur des caractéristiques spécifiques de SOAP.