Question 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 les plus grands avantages pour REST over SOAP sont:

  1. REST est plus dynamique, pas besoin de créer et de mettre à jour UDDI.

  2. REST n'est pas limité au format XML. Les services Web REST peuvent envoyer texte brut, JSON, et aussi XML.

Mais le SOAP est plus standardisé (Ex, sécurité).

Alors, ai-je raison sur ces points?


987
2017-11-09 23:11


origine


Réponses:


Malheureusement, il y a beaucoup de désinformation et d'idées fausses autour de REST. Non seulement votre question et le répondre par @cmd refléter 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, puisque le premier est un protocole (ou du moins essaie d'être) et le second est un style architectural. C'est probablement l'une des sources de confusion autour de cela, puisque les gens ont tendance à appeler REST n'importe quelle 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 y a un contrat rigide entre le client et le serveur, et tout devrait se casser si l'un ou l'autre camp change quelque chose. Vous avez besoin de mises à jour constantes à la suite de tout changement, mais il est plus facile de déterminer si le contrat est suivi.

Un client REST ressemble plus à un navigateur. C'est un client générique qui sait 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 utilisez les méthodes standard et créez les actions avec eux sur votre type de média. Si c'est bien fait, il y a moins de couplage, et les changements peuvent être traités plus gracieusement. Un client est supposé entrer dans un service REST avec une connaissance nulle de l'API, à l'exception du point d'entrée et du type de média. Dans SOAP, le client a besoin de connaissances préalables sur tout ce qu'il utilisera, ou il ne commencera même pas l'interaction. En outre, un client REST peut être étendu par 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 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. Ce 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 d'URI normalisé.

  • REST n'est pas un mappage des méthodes CRUD vers HTTP. Lis ce répondez 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 standardisées, c'est donc ce que vous utilisez lorsque vous effectuez REST over 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 censé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 passent complètement à côté de ce point. Ils ne documentent pas seulement quelque chose qui est censé suivre la norme, mais quand vous faites cela, vous associez le client à un moment particulier de l'évolution de l'API, et tout changement sur l'API doit être documenté et appliqué, ou il 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édias, et le site Web vous fournit les liens vers ceux-ci. Une API REST doit faire la même chose. Si nous avons conçu le web comme les gens pensent que REST devrait être fait, au lieu d'avoir une page d'accueil avec des liens vers des questions et réponses, nous aurions une documentation statique expliquant que pour afficher une question, vous devez prendre l'URI stackoverflow.com/questions/<id>, remplacez id par Question.id et collez-le sur votre navigateur. C'est un non-sens, mais c'est ce que beaucoup de gens pensent que REST est.

Ce dernier point ne peut être assez souligné. Si vos clients créent 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 clairement indiqué sur ce blog: Les API REST doivent être basées sur un lien hypertexte.

Avec ce qui précède, vous réaliserez que, bien que REST ne soit pas limité à XML, pour le faire correctement avec tout autre format, vous devrez concevoir et normaliser un certain format pour vos liens. Les liens hypertexte sont standard en XML, mais pas en JSON. Il y a des projets de normes pour JSON, comme HAL.

Enfin, REST n'est pas pour 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 ont appelé par erreur REST et ne s'aventurent jamais au-delà. REST est difficile à faire parfois, surtout au début, mais il paie 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 quelque chose rapidement et facilement, ne vous souciez pas d'obtenir REST correctement. Ce n'est probablement pas ce que vous cherchez. Si vous avez besoin de quelque chose qui devra rester en ligne pendant des années, voire des décennies, REST est fait pour vous.


1461
2017-11-10 00:45



REST contre SOAP est ne pas la bonne question à poser.

REST, contrairement à SOAP est ne pas un protocole.

REST est un style architectural et un conception pour les architectures logicielles réseau.

REST les concepts 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 médias comprennent XML, JSON, et RDF. Les ressources sont manipulées par des composants. Les composants demandent et manipulent les ressources via une interface standard uniforme. 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 éclaire le fait que REST et HTTP sont souvent utilisés en tandem. Ceci est principalement dû à la simplicité de HTTP et à sa mise en correspondance très naturelle avec les principes RESTful.

Principes fondamentaux de REST

Communication client-serveur

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

Apatride

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

Cacheable

Des contraintes de cache peuvent être utilisées, ce qui permet de marquer les données de réponse comme pouvant être mises en mémoire cache ou non. Toute donnée marquée comme pouvant être mise en mémoire cache peut être réutilisée comme réponse à la même demande ultérieure.

Interface uniforme

Tous les composants doivent interagir à travers une seule interface uniforme. Comme toutes les interactions entre les 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 modifications de mise en œuvre peuvent être effectuées isolément. 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 changeant l'interface, vous n'avez pas de chance car REST l'interdit. Du bon côté, cependant, REST est optimisé pour le web, d'où une 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 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 poster sur REST Principes de conception pour plus de détails sur DU REPOS et les balles mentionnées ci-dessus.

MODIFIER: mettre à jour le contenu en fonction des commentaires


245
2017-11-09 23:19



SAVON (Protocole d'accès aux objets simple) et REST (Transfert d'état de représentation) les deux sont beaux à leur manière. Donc je ne les compare pas. Au lieu de cela, j'essaye de représenter l'image, quand j'ai préféré utiliser REST et quand SOAP.

Qu'est-ce que la charge utile? 

Lorsque les données sont envoyées sur Internet, chaque unité transmise comprend à la fois les 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 la charge utile. En général, la charge utile est la donnée qui est transportée 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 Télégramme et nous savons tous que le coût du télégramme dépendra de quelques mots.

Alors dites-moi parmi ces deux messages ci-dessous, lequel est moins cher à envoyer?

<name>Arin</name>

ou

"name": "Arin"

Je sais que votre réponse sera la deuxième, bien que les deux représentant le même message est moins cher en ce qui concerne le coût.

Donc j'essaie de dire ça, envoyer des données sur le réseau au format JSON est moins cher que de l'envoyer au format XML en ce qui concerne la charge utile.

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

Maintenant, SOAP supporte le seul XML, mais il a aussi ses avantages. 

Vraiment! Comment?

SOAP s'appuie sur XML de trois façons Enveloppe - qui définit ce qui est dans le message et comment le traiter.

Un ensemble de règles de codage pour les types de données, et enfin la mise en page des appels de procédure et des réponses recueillies.

Cette enveloppe est envoyée via un transport (HTTP / HTTPS) et un appel 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 requête mais REST ne 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", alors allez un peu plus loin sur ces mots.

Lorsque nous parlons de REST sur HTTP, toutes les mesures de sécurité appliquées HTTP sont héritées, et cela s'appelle sécurité au niveau du transport et il ne sécurise les messages que pendant 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 traverser 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 que HTTP.Donc, le repos n'est pas plus sûr complètement, non?

Mais SOAP prend en charge SSL juste 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 contre création du message à sa consommation. Donc, pour la sécurité au niveau du transport, nous avons trouvé une faille qui peut être évitée en utilisant WS-Security.

En dehors de cela, comme REST est limité par son protocole HTTP Par conséquent, le support des transactions n'est pas conforme à l'ACID et ne peut pas fournir une validation en deux phases à travers les ressources transnationales distribuées.

Mais SOAP a un support complet pour les deux 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 soutient également validation en deux phases sur des ressources distribuées.

Je ne tire aucune conclusion, mais je préférerai le service Web basé sur SOAP alors que la sécurité, les transactions, etc. sont les principales préoccupations.

Voici le "Tutoriel Java EE 6" où ils ont dit Une conception RESTful peut être appropriée lorsque les conditions suivantes sont remplies. Regarde.

J'espère que vous avez aimé lire ma réponse.


189
2018-06-14 19:48



DU REPOS(présentation State Ttransfert)
REST est un style architectural. Il ne définit pas autant de standards comme le SOAP. REST permet d'exposer les API publiques (API Facebook, API Google Maps) via 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 seule interface cohérente.

SAVON(Simplanter Objecter UNEccess Protocol)
SOAP apporte son propre protocole et se concentre sur l'exposition de parties de la logique applicative (pas de données) en tant que services. SOAP expose les opérations. SOAP se concentre sur l'accès aux opérations nommées, chaque opération implémente une logique métier. Bien que le SOAP soit communément appelé services Web c'est abusif. SOAP a très peu de choses à faire avec le Web. REST fournit vrai services Web basé sur les URI et HTTP.

Pourquoi REST? 

  • Depuis REST utilise HTTP standard, il est beaucoup plus simple à peu près jamais.
  • REST est plus facile à implémenter, nécessite moins de bande passante et de ressources.
  • REST autorise de nombreux formats de données différents alors que SOAP ne permet que le XML.
  • REST permet une meilleure prise en charge des clients de navigateur en raison de sa prise en charge de JSON.
  • REST a de meilleures performances et é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 nous avons des ressources limitées. Ou nous voulons créer une API qui sera facilement utilisée par d'autres développeurs publiquement alors nous devrions aller avec REST.
  • Si nous avons besoin d'opérations CRUD sans état, optez pour REST.
  • REST est couramment utilisé dans les médias sociaux, le web chat, les services mobiles et les API publiques comme Google Maps.
  • Le service RESTful renvoie différents MediaTypes pour la même ressource, en fonction du paramètre d'en-tête de requête "Accepter". application/xml ou application/json pour POST et /user/1234.json ou GET /user/1234.xml oublier.
  • Les services REST sont destinés à être appelés par l'application côté client et non directement par l'utilisateur final.
  • ST en REST vient de State Ttransfert. Vous transférez l'état au lieu de le stocker dans le serveur, ce qui rend les services REST évolutifs.

Pourquoi SOAP? 

  • SOAP n'est pas très facile à implémenter et nécessite plus de bande passante et de ressources.
  • La demande de message SOAP est traitée plus lentement par rapport à REST et n'utilise pas le mécanisme de mise en cache Web.
  • WS-Security: Alors que SOAP prend en charge SSL (tout comme REST), il prend également en charge WS-Security, qui ajoute certaines fonctionnalités de sécurité d'entreprise.
  • WS-AtomicTransaction: 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 n'a pas de système de messagerie standard et s'attend à ce que les clients résolvent les problèmes 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. Comme si nous créons un service web pour les passerelles de paiement, les finances et les télécommunications, alors nous devrions aller avec SOAP car ici, une haute sécurité est nécessaire.

enter image description here

source1
source2


81
2017-12-08 23:38



D'autres réponses ont donné des différences importantes et expliquées en détail. Donc, je vous éviterais ce genre de réponses et vous demanderais si vous êtes encore confus, si c'est le cas, vous voudrez peut-être jeter un coup d'œil à cette simple analogie. enter image description here


60
2018-06-23 05:19



La décision entre les deux sera votre premier choix dans la conception d'un service Web, il est donc important de comprendre les avantages et les inconvénients des deux. Il est également important, dans le débat parfois houleux entre les deux philosophies, de séparer la réalité de la rhétorique.

Les fondamentaux de REST

  • Tout dans REST est considéré comme une ressource.
  • Chaque ressource est identifiée par un URI.
  • Utilise des interfaces uniformes. Les ressources sont gérées à l'aide des opérations POST, GET, PUT, DELETE qui sont similaires aux opérations CRUD (Create, Read, Update et Delete).
  • Soyez apatride. Chaque requête est une requête indépendante. Chaque requête du client au serveur doit contenir toutes les informations nécessaires pour comprendre la requête.
  • Les communications sont effectuées via des représentations. Par exemple, XML, JSON RESTful Web Services. Les services Web RESTful sont basés sur des méthodes HTTP et le concept de REST. Un service Web RESTful définit généralement l'URI de base pour les services; les types MIME supportés (XML, texte, JSON, définis par l'utilisateur, ...) et l'ensemble des opérations (POST, GET, PUT, DELETE) qui sont supportées.

Les fondamentaux du SOAP

  • WSDL définit le contrat entre le client et le service et est statique par nature.
  • SOAP construit un protocole XML basé sur HTTP ou parfois TCP / IP.
  • SOAP décrit les fonctions et les types de données.
  • SOAP est un successeur de XML-RPC et est très similaire, mais décrit une façon standard de communiquer.
  • Plusieurs langages de programmation supportent nativement SOAP, vous y alimentez généralement une URL de service Web et vous pouvez appeler ses fonctions de service Web sans avoir besoin de code spécifique.
  • Les données binaires envoyées doivent d'abord être codées dans un format tel que codé en base64.
  • A plusieurs protocoles et technologies qui s'y rapportent: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

L'un des principaux avantages de SOAP est que vous avez une description de service WSDL. Vous pouvez pratiquement découvrir le service automatiquement et générer un proxy client utilisable à partir de cette description de service (générer les appels de service, les types de données nécessaires pour les méthodes, etc.). Notez qu'avec la version 2.0, WSDL supporte tous les verbes HTTP et peut aussi être utilisé pour documenter les services RESTful, mais il existe une alternative moins verbeuse dans WADL (Web Application Description Language) à cette fin.

Avec les services RESTful, la sécurité des messages est assurée par le protocole de transport (HTTPS) et est point-à-point seulement. Il n'a pas de système de messagerie standard et s'attend à ce que les clients résolvent les problèmes de communication en réessayant. SOAP a une logique réussie / retry intégrée et fournit une fiabilité de bout en bout même à travers les intermédiaires SOAP.

L'un des principaux avantages de RESTful API est qu'il est flexible pour la représentation des données. Par exemple, vous pouvez sérialiser vos données au format XML ou JSON. Les API RESTful sont plus propres ou plus faciles à comprendre car elles ajoutent un élément d'utilisation des URI normalisées et donnent de l'importance au verbe HTTP utilisé (à savoir, GET, POST, PUT et DELETE).

Les services RESTful sont également légers, c'est-à-dire qu'ils n'ont pas beaucoup de balisage XML supplémentaire. Pour invoquer l'API RESTful, vous n'avez besoin que d'un navigateur ou d'une pile HTTP et à peu près tous les périphériques ou machines connectés à un réseau ont cela.

Avantages de REST

  • Comme REST utilise le protocole HTTP standard, il est beaucoup plus simple à tous les égards. Créer des clients, développer des API, la documentation est beaucoup plus facile à comprendre, et il n'y a pas beaucoup de choses que REST ne fait pas plus facile / meilleur que SOAP.
  • REST permet de nombreux formats de données différents alors que SOAP ne permet que le XML. Bien que cela puisse sembler ajouter de la complexité à REST parce que vous devez gérer plusieurs formats, selon mon expérience, cela a été plutôt bénéfique. JSON est généralement un meilleur ajustement pour les données et analyse beaucoup plus rapidement. REST permet une meilleure prise en charge des clients de navigateur en raison de sa prise en charge de JSON.
  • REST a de meilleures performances et évolutivité. Les lectures REST peuvent être mises en cache; Les lectures basées sur SOAP ne peuvent pas être mises en cache.
  • Aucun outil coûteux nécessite d'interagir avec le service Web
  • Courte courbe d'apprentissage
  • Efficace (SOAP utilise XML pour tous les messages, REST peut utiliser des formats de message plus petits)
  • Rapide (pas de traitement étendu requis)
  • Plus proche des autres technologies Web dans la philosophie de conception

Avantages de SOAP

  • WS-Security: Alors que SOAP prend en charge SSL (tout comme REST), il prend également en charge WS-Security, qui ajoute certaines fonctionnalités de sécurité d'entreprise. Prend en charge l'identité par le biais d'intermédiaires, pas seulement point à point (SSL). Il fournit également une implémentation standard de l'intégrité des données et de la confidentialité des données. L'appeler "Enterprise" ne veut pas dire qu'il est plus sécurisé, il prend simplement en charge certains outils de sécurité dont les services Internet typiques n'ont pas besoin, en fait, ils ne sont nécessaires que dans quelques scénarios "d'entreprise".
  • WS-AtomicTransaction: Besoin de Transactions ACID sur un service, vous allez avoir besoin de SOAP. Tandis que REST prend en charge les transactions, il n'est pas aussi complet et n'est pas conforme à l'ACID. Heureusement, les transactions ACID n'ont presque jamais de sens sur Internet. REST est limité par HTTP lui-même qui ne peut pas fournir une validation en deux phases à travers les ressources transactionnelles distribuées, mais SOAP le peut. Les applications Internet n'ont pas besoin de ce niveau de fiabilité transactionnelle, ce que font parfois les applications d'entreprise.
  • WS-ReliableMessaging: Rest n'a pas de système de messagerie standard et s'attend à ce que les clients résolvent les problèmes de communication en réessayant. SOAP a une logique réussie / retry intégrée et fournit une fiabilité de bout en bout même à travers les intermédiaires SOAP.
  • Langage, plateforme et transport indépendants (REST nécessite l'utilisation de HTTP)
  • Fonctionne bien dans les environnements d'entreprise distribués (REST suppose une communication point-à-point directe)
  • Standardisé
  • Fournit une extensibilité pré-construction significative sous la forme des normes WS
  • Gestion des erreurs intégrée
  • Automatisation lorsqu'elle est utilisée avec certains produits de langage

Où utiliser REST 

Les domaines dans lesquels REST fonctionne bien sont:

  • Bande passante et ressources limitées rappelez-vous que la structure de retour est vraiment dans n'importe quel format (développeur défini). De plus, n'importe quel navigateur peut être utilisé car l'approche REST utilise les verbes standard GET, PUT, POST et DELETE. Encore une fois, n'oubliez pas que REST peut également utiliser l'objet XMLHttpRequest que les navigateurs les plus modernes prennent en charge aujourd'hui, ce qui ajoute un bonus d'AJAX.
  • opérations sans état: Si une opération doit être poursuivie, alors REST n'est pas la meilleure approche et SOAP peut mieux l'adapter. Cependant, si vous avez besoin d'opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) sans état, alors REST l'est.
  • Situations de cache: Si l'information peut être mise en cache à cause du fonctionnement sans état de l'approche REST, c'est parfait.

Où utiliser SOAP

domaines où SOAP fonctionne comme une excellente solution:

  • Traitement asynchrone et invocation: Si votre application a besoin d'un niveau de fiabilité et de sécurité garanti, SOAP 1.2 propose des standards supplémentaires pour assurer ce type d'opération. Des choses comme WSRM - WS-Reliable Messaging.
  • Contrats formels: Si les deux parties (fournisseur et consommateur) doivent se mettre d'accord sur le format d'échange alors SOAP 1.2 donne les spécifications rigides pour ce type d'interaction.
  • Opérations avec état: Si l'application a besoin d'informations contextuelles et de gestion d'état conversationnel, SOAP 1.2 a la spécification supplémentaire dans la structure WS pour prendre en charge ces éléments (sécurité, transactions, coordination, etc.). Comparativement, l'approche REST permettrait aux développeurs de construire cette plomberie personnalisée.

43
2018-04-21 11:12



Différence entre le repos et le savon

SAVON

  1. SOAP est un protocole.
  2. SOAP signifie Simple Object Access Protocol.
  3. SOAP ne peut pas utiliser REST parce que c'est un protocole.
  4. SOAP utilise des interfaces de services pour exposer la logique métier.
  5. SOAP définit des standards à suivre strictement.
  6. SOAP nécessite plus de bande passante et de ressources que REST.
  7. SOAP définit sa propre sécurité.
  8. SOAP autorise le format de données XML uniquement.
  9. SOAP est moins préféré que REST.

DU REPOS

  1. REST est un style architectural.
  2. REST signifie Representational State Transfer.
  3. REST peut utiliser les services Web SOAP parce que c'est un concept et peut utiliser n'importe quel protocole comme HTTP, SOAP.
  4. REST utilise URI pour exposer la logique métier.
  5. REST ne définit pas trop de standards comme SOAP.
  6. REST nécessite moins de bande passante et de ressources que SOAP.
  7. Les services Web RESTful héritent des mesures de sécurité du transport sous-jacent.
  8. REST permet différents formats de données tels que texte brut, HTML, XML, JSON, etc.
  9. REST plus préféré que SOAP.

Pour plus de détails s'il vous plaît voir ici


29
2018-03-21 12:47



À mon humble avis vous ne pouvez pas comparer SOAP et REST où ce sont deux choses différentes.

SAVONest un protocole et DU REPOS est un modèle architectural de logiciel. Il y a beaucoup d'idées fausses sur Internet pour SOAP vs REST.

SAVON définit un format de message basé sur XML que les applications compatibles avec le service Web utilisent pour communiquer les unes avec les autres sur Internet. Pour ce faire, les applications nécessitent une connaissance préalable du contrat de message, des types de données, etc.

DU REPOS 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.


12
2018-01-17 00:17



Ajout pour:

++ Une erreur souvent commise lors de l'approche de REST est de considérer cela comme des "services web avec URL" - de penser à REST comme un autre mécanisme d'appel de procédure distante (RPC), comme SOAP, mais invoqué via des URL HTTP simples et sans SOAP. Espaces de noms XML.

++ Au contraire, REST a peu à voir avec RPC. Alors que RPC est axé sur le service et axé sur les actions et les verbes, REST est orienté ressources, en mettant l'accent sur les choses et les noms qui composent une application.


5
2017-09-20 08:02