Representational State Transfer (REST) ​​et SOAP (Simple Object Access Protocol)

Question

Quelqu'un peut-il expliquer ce qui est RESTE et ce qui est SOAP en langage simple? Et comment fonctionnent les services Web?

Answer 1

Explication simple sur SOAP et REST

SOAP - "Simple Object Access Protocol"

SOAP est une méthode de transfert de messages, ou de petites quantités d’informations, sur Internet. Les messages SOAP sont formatés en XML et sont généralement envoyés via HTTP (protocole de transfert hypertexte).

---

Reste - Transfert d'état représentationnel

Reste est un moyen simple d’envoyer et de recevoir des données entre le client et le serveur et il n’a pas beaucoup de normes définies. Vous pouvez envoyer et recevoir des données au format JSON, XML ou même en texte brut. Il est léger comparé au savon.

---

Answer 2

Les deux méthodes sont utilisées par de nombreux grands acteurs. C'est une question de préférence. Ma préférence est REST car son utilisation et sa compréhension sont plus simples.

Protocole SOAP (Simple Object Access Protocol):

• SOAP construit un protocole XML en plus de HTTP ou parfois de 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 un moyen standard de communiquer.
• Plusieurs langages de programmation prennent en charge SOAP en natif, vous lui attribuez généralement une URL de service Web et vous pouvez appeler ses fonctions de service Web sans recourir à un 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 s'y rapportant: WSDL, XSD, SOAP, WS-Addressing

Transfert d'état représentationnel (REST):

• REST n'a pas besoin d'être sur HTTP, mais la plupart de mes points ci-dessous auront un biais HTTP.
• REST est très léger. Attendez une minute, nous n’avons pas besoin de toute cette complexité créée par SOAP.
• Utilise généralement des méthodes HTTP normales au lieu d’un grand format XML décrivant tout. Par exemple, pour obtenir une ressource que vous utilisez HTTP GET, pour mettre une ressource sur le serveur, utilisez HTTP PUT. Pour supprimer une ressource sur le serveur, utilisez HTTP DELETE.
• REST est très simple car il utilise les méthodes HTTP GET, POST et PUT pour mettre à jour les ressources sur le serveur.
• REST est généralement mieux utilisé avec architecture axée sur les ressources (ROA). Dans ce mode de pensée, tout est une ressource et vous utiliseriez ces ressources.
• Tant que votre langage de programmation possède une bibliothèque HTTP, et la plupart en possèdent, vous pouvez très facilement utiliser un protocole HTTP REST.
• Des données binaires ou des ressources binaires peuvent être simplement livrées sur leur demande.

Il y a débats sans fin sur REST vs SOAP sur Google .

Mon préféré est celui-ci . Mise à jour du 27 novembre 2013: le site de Paul Prescod semble être hors ligne et cet article n'est plus disponible. Des copies sont disponibles sur le Wayback Machine ou en tant que PDF à - CiteSeerX .

Answer 3

RESTE

Je comprends que l’idée principale de REST est extrêmement simple. Nous utilisons des navigateurs Web depuis des années et nous avons constaté à quel point les sites Web sont faciles, flexibles, performants, etc. Les sites HTML utilisent des hyperliens et des formulaires comme principal moyen d'interaction avec l'utilisateur. Leur objectif principal est de nous permettre, clients, de ne connaître que les liens que nous pouvons utiliser dans l'état actuel . Et REST dit simplement: "Pourquoi ne pas utiliser les mêmes principes pour conduire un ordinateur plutôt que des clients humains via notre application?" Combinez cela avec la puissance de l'infrastructure WWW et vous obtiendrez un outil formidable pour la création d'excellentes applications distribuées.

Une autre explication possible est celle des personnes ayant une pensée mathématique. Chaque application est fondamentalement une machine à états, les actions de la logique applicative constituant des transitions d’états. L'idée de REST est de mapper chaque transition sur une requête adressée à une ressource et de fournir aux clients des liens représentant les transitions disponibles dans l'état actuel. Ainsi, il modélise la machine d'état via des représentations et des liens. C'est pourquoi on l'appelle le transfert d'état représentatif.

Il est assez surprenant que toutes les réponses semblent se concentrer soit sur le format du message, soit sur l'utilisation des verbes HTTP. En fait, le format du message n'a pas d'importance, REST peut utiliser n'importe lequel à condition que le développeur du service le documente. Les verbes HTTP ne font qu'un service CRUD, mais pas encore RESTful. Ce qui transforme réellement un service en un service REST, ce sont les liens hypertexte (ou contrôles hypermédia) intégrés aux réponses du serveur avec les données, et leur quantité doit être suffisante pour que tout client puisse choisir la prochaine action parmi ces liens.

Malheureusement, il est assez difficile de trouver les informations correctes sur le Web REST, à l'exception du thèse de Roy Fielding . (C'est lui qui a dérivé REST). Je recommanderais le livre 'REST in Practice' car il fournit un didacticiel détaillé étape par étape sur la manière de passer de SOAP à REST.

SOAP

C'est l'une des formes possibles du style d'architecture RPC (appel de procédure distante). En substance, il s’agit simplement d’une technologie qui permet aux clients d’appeler des méthodes de serveur via des limites de service (réseau, processus, etc.) comme s’ils appelaient des méthodes locales. Bien sûr, cela diffère de l'appel des méthodes locales en termes de vitesse, de fiabilité, etc., mais l'idée est aussi simple que cela.

Comparé

Les détails tels que les protocoles de transport, les formats de message, xsd, wsdl, etc. importent peu lorsque l’on compare toute forme de RPC à REST. La principale différence est qu'un service RPC réinvente la bicyclette en concevant son propre protocole d'application dans l'API RPC avec la sémantique qu'il est le seul à connaître. Par conséquent, tous les clients doivent comprendre ce protocole avant d'utiliser le service, et aucune infrastructure générique telle que les caches ne peut être construite en raison de la sémantique propriétaire de toutes les demandes. De plus, les API RPC ne suggèrent pas quelles actions sont autorisées dans l'état actuel, cela doit être dérivé d'une documentation supplémentaire. REST, d’autre part, implique l’utilisation d’interfaces uniformes pour permettre à divers clients d’avoir une certaine compréhension de la sémantique des API et de contrôles hypermédia (liens) pour mettre en évidence les options disponibles dans chaque état. Ainsi, il permet de mettre en cache les réponses des services d’échelle et de rendre l’utilisation correcte des API facilement identifiable sans documentation supplémentaire.

D'une certaine manière, SOAP (comme tout autre RPC) est une tentative de tunnelisation à travers une limite de service, en considérant le support de connexion comme une boîte noire capable uniquement de transmettre des messages. REST est une décision de reconnaître que le Web est un énorme système d’information distribué, d’accepter le monde tel quel et d’apprendre à le maîtriser au lieu de le combattre.

SOAP semble être idéal pour les API de réseau internes, lorsque vous contrôlez à la fois le serveur et les clients, et que les interactions ne sont pas trop complexes. Il est plus naturel que les développeurs l'utilisent. Cependant, pour une API publique utilisée par de nombreuses parties indépendantes, complexe et volumineuse, REST devrait être mieux adapté. Mais cette dernière comparaison est très floue.

Mettre à jour

Mon expérience a montré de manière inattendue que le développement de REST était plus difficile que celui de SOAP. Au moins pour .NET. Bien qu'il existe d'excellents frameworks tels que l'API Web ASP.NET, aucun outil ne génère automatiquement un proxy côté client. Rien de tel que "Ajouter une référence au service Web" ou "Ajouter une référence au service WCF". Il faut écrire manuellement tous les codes de sérialisation et d’interrogation de service. Et mec, ça fait beaucoup de code passe-partout. Je pense que le développement de REST nécessite quelque chose de similaire au WSDL et à la mise en œuvre d'outils pour chaque plate-forme de développement. En fait, il semble y avoir un bon terrain: WADL ou WSDL 2. , mais aucune des normes ne semble bien supportée.

Mise à jour (janvier 2016)

Il se trouve qu’il existe maintenant une large gamme d’outils pour la définition de l’API REST. Ma préférence personnelle est actuellement RAML .

Comment fonctionnent les services Web

Cette question est trop vaste, car elle dépend de l’architecture et de la technologie utilisées dans le service Web spécifique. Mais en général, un service Web est simplement une application du Web capable d’accepter des demandes de clients et de renvoyer des réponses. Il est exposé au Web, il s’agit donc d’un service web , disponible 24 heures sur 24, 7 jours sur 7, c’est pourquoi il s’agit d’un service . Bien sûr, cela résout certains problèmes (sinon, pourquoi quelqu'un utiliserait-il un service Web) pour ses clients.

Answer 4

C'est l'explication la plus simple que vous trouverez jamais.

Cet article présente un récit mari à femme, où le mari explique à REST son épouse, en termes purement profanes. Doit lire!

comment-je-expliqué-reste-à-ma-femme (lien original)
comment-je-expliqué-reste-à-ma-femme (2013-07-19 lien de travail)

Answer 5

SOAP - Le protocole d'accès aux objets simples est un protocole !

REST - Le transfert d'état représentatif est un style architectural !

SOAP est un protocole XML utilisé pour transférer des messages, généralement via HTTP

REST et SOAP sont sans doute non mutuellement exclusifs. Une architecture RESTful peut utiliser HTTP ou SOAP ou un autre protocole de communication. REST est optimisé pour le Web et donc HTTP constitue un choix parfait. HTTP est également le protocole uniquement décrit dans l'article de Roy Fielding.

Bien que REST et SOAP soient clairement très différents, la question 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 client-serveur dans princple.

Sans état

Chaque demande client adressée 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. Nous discuterons de la représentation sans état plus en détail ultérieurement.

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 sur Principes de conception REST pour plus de détails sur RESTE et les puces mentionnées ci-dessus.

Answer 6

J'aime la réponse de Brian R. Bondy. Je voulais juste ajouter que Wikipedia fournit une description claire de RESTE . L'article le distingue de SOAP.

REST est un échange d'informations d'état, effectué le plus simplement possible.

SOAP est un protocole de messagerie utilisant XML.

L'une des principales raisons pour lesquelles de nombreuses personnes sont passées de SOAP à REST est que les normes WS- * (appelées WS Splat) associées aux services Web basés sur SOAP sont extrêmement compliqués. Voir wikipedia pour obtenir une liste des spécifications. Chacune de ces spécifications est très compliquée.

EDIT: pour une raison quelconque, les liens ne s'affichent pas correctement. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Answer 7

Les services Web SOAP et REST peuvent également utiliser le protocole HTTP et d'autres protocoles (le simple fait de mentionner SOAP peut être le protocole sous-jacent de REST). Je ne parlerai que des protocoles HTTP SOAP et REST, car il s’agit de leur utilisation la plus fréquente.

SOAP

SOAP ("simple" protocole d'accès aux objets) est un protocole (et un standard W3C ). Il définit comment créer, envoyer et traiter les messages SOAP.

• Les messages SOAP sont des documents XML dotés d'une structure spécifique: ils contiennent une enveloppe qui contient l'en-tête et la section body. Le corps contient les données réelles - nous voulons envoyer - dans un format XML. Il existe deux styles d’encodage , mais , nous choisissons généralement littéral , ce qui signifie que notre application ou son pilote SOAP effectue la sérialisation XML et la désérialisation des données.

• Les messages SOAP voyagent en tant que messages HTTP avec un sous-type MIME SOAP + XML. Ces messages HTTP peuvent être composés de plusieurs parties. Nous pouvons donc éventuellement joindre des fichiers à des messages SOAP.

• Bien entendu, nous utilisons une architecture client-serveur, de sorte que les clients SOAP envoient des demandes aux serveurs Web SOAP et les services renvoient les réponses aux clients. La plupart des services Web utilisent un fichier WSDL pour décrire le service. Le fichier WSDL contient le schéma XML (XSD ci-après) des données à envoyer et la liaison WSDL qui définit la manière dont le service Web est lié au protocole HTTP. Il existe deux styles de liaison : RPC et document. Par la liaison de style RPC, le corps SOAP contient la représentation d'un appel d'opération avec les paramètres (demandes HTTP) ou les valeurs de retour (réponse HTTP). Les paramètres et les valeurs de retour sont validés par rapport au XSD. Par la liaison de style de document, le corps SOAP contient un document XML validé par rapport à XSD. Je pense que le style de reliure de document convient mieux aux systèmes basés sur des événements, mais je n'ai jamais utilisé ce style de reliure. Le style de liaison RPC étant plus répandu, la plupart des gens utilisent SOAP à des fins XML/RPC par des applications distribuées. Les services Web se trouvent généralement en demandant à un serveur UDDI . Les serveurs UDDI sont des registres qui stockent l'emplacement des services Web.

SOAP RPC

Ainsi, à mon avis, le service Web le plus répandu SOAP utilise le style de liaison RPC et le style d'encodage littéral. Il présente les propriétés suivantes:

• Il mappe les URL aux opérations.
• Il envoie des messages avec le sous-type MIME SOAP + XML.
• Il peut avoir un magasin de session côté serveur, il n'y a pas de contrainte à ce sujet.
• Les pilotes clients SOAP utilisent le fichier WSDL du service pour convertir les opérations RPC en méthodes. L'application côté client communique avec le service Web SOAP en appelant ces méthodes. Ainsi, la plupart des clients SOAP divisent les modifications d'interface (noms de méthodes et/ou modifications de paramètres résultants).
• Il est possible d'écrire des clients SOAP qui n'interrompront pas les modifications d'interface avec RDF et rechercheront les opérations par sémantique, mais un service Web sémantique sont très rares et ils n’ont pas nécessairement un client qui ne casse pas (je suppose).

REST

REST (Representational State Transfer) est un style d'architecture décrit dans la thèse de Roy Fielding. Cela ne concerne pas les protocoles comme SOAP. Il commence par un style d'architecture nul n'ayant pas de contrainte et définit les contraintes de l'architecture REST une par une. Les gens utilisent le terme RESTful pour les services Web qui remplissent toutes les contraintes REST, mais selon Roy Fielding, il n’existe pas de choses telles que les niveaux REST . Lorsqu'un service Web ne respecte pas toutes les contraintes REST, il ne s'agit pas d'un service Web REST.

Contraintes REST

• Architecture client-serveur - Je pense que cette partie est familière à tout le monde. Les clients REST communiquent avec les _services Web REST, ils conservent l'état de données commun - l'état des ressources ci-après - et le servent aux clients.
• Stateless - La partie "transfert d'état" de l'abréviation: REST. Les clients conservent l'état du client (état de session/application), les services ne doivent donc pas avoir de stockage de session. Les clients transfèrent la partie pertinente de l'état client par chaque demande aux services qui répondent avec la partie pertinente de l'état de la ressource (maintenue par eux). Les demandes n'ont donc pas de contexte, elles contiennent toujours les informations nécessaires pour les traiter. Par exemple, avec l'authentification de base HTTP, le nom d'utilisateur et le mot de passe sont stockés par le client, qui les envoie à chaque demande. L'authentification s'effectue donc pour chaque demande. Ceci est très différent des applications Web habituelles où l’authentification ne se fait que par connexion. Nous pouvons utiliser n’importe quel mécanisme de stockage de données côté client, comme en mémoire (javascript), les cookies, le stockage local, etc., pour conserver certaines parties de l’état du client si nous le souhaitons. La raison de la contrainte d'apatridie, que le serveur s'adapte bien - même avec une charge très élevée (des millions d'utilisateurs) - lorsqu'il n'a pas à gérer la session de chaque client.
• Cache - La réponse doit contenir des informations à ce sujet. Elle peut être mise en cache par le client ou non. Cela améliore davantage l'évolutivité.

• Interface uniforme

  • Identification des ressources - REST ressource est la même chose que RDF ressource. Selon Fielding, si vous pouvez nommer quelque chose, il peut s'agir d'une ressource, par exemple: "la météo locale actuelle" peut être une ressource, ou "votre téléphone mobile" peut être une ressource, ou "un document Web spécifique" peut être une ressource. Pour identifier une ressource, vous pouvez utiliser des identificateurs de ressource: URL et URN (par exemple numéro ISBN par livres ). Un identificateur unique ne doit appartenir qu'à une ressource spécifique, mais une ressource unique peut avoir plusieurs identifiants, que nous exploitons fréquemment, par exemple, en paginant avec des URL telles que https://example.com/api/v1/users?offset=50&count=25. Les URL ont des spécifications , par exemple des URL avec les mêmes chemins mais des requêtes différentes ne sont pas identiques, ou la partie chemin doit contenir les données hiérarchiques de l'URL et la partie requête doit contenir les données non hiérarchiques. Voici les bases de la création d'URL par REST. Btw. la structure de l'URL n'a d'importance que pour les développeurs de services, un vrai client REST ne le concerne pas. Une autre question fréquemment posée est la gestion des versions d'API, qui est facile car, selon Fielding, la seule chose constante par ressource est la sémantique. Si la sémantique change, vous pouvez ajouter un nouveau numéro de version. Vous pouvez utiliser la version classique à 3 numéros et ajouter uniquement le nombre majeur aux URL (https://example.com/api/v1/). Donc, avec les modifications rétrocompatibles, rien ne se passe; avec les modifications non rétrocompatibles, vous obtiendrez une sémantique non rétrocompatible avec une nouvelle racine API https://example.com/api/v2/. Ainsi, les anciens clients ne casseront pas, car ils peuvent utiliser le https://example.com/api/v1/ avec l'ancienne sémantique.
  • Manipulation de ressources par le biais de représentations - Vous pouvez manipuler les données liées aux ressources (état de la ressource) en envoyant la représentation souhaitée des ressources - avec la méthode HTTP et l'identificateur de ressource - au service REST. Par exemple, si vous souhaitez renommer un utilisateur après le mariage, vous pouvez envoyer une demande PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} dans laquelle le {name: "Mrs Smith"} est une représentation JSON de l'état de la ressource prévue, autrement dit: le nouveau nom. Ceci se produit vica-inversement, le service envoie des représentations de ressources aux clients afin de changer leurs états. Par exemple, si nous voulons lire le nouveau nom, nous pouvons envoyer une demande de récupération GET https://example.com/api/v1/users/1?fields="name", qui entraîne une réponse 200 ok, {name: "Mrs Smith"}. Nous pouvons donc utiliser cette représentation pour modifier l’état du client. Par exemple, nous pouvons afficher un message "Bienvenue sur notre page, Mme Smith!" message. Une ressource peut avoir plusieurs représentations en fonction de l'identifiant de ressource (URL) ou de l'en-tête accept que nous avons envoyé avec la demande. Par exemple, nous pouvons envoyer une image de Mme Smith (probablement pas nue) si image/jpeg est demandé.
  • Messages auto-descriptifs - Les messages doivent contenir des informations sur la manière de les traiter. Par exemple, méthode URI et HTTP, en-tête de type de contenu, en-têtes de cache, RDF qui décrit la signification des données, etc. Il est important d'utiliser des méthodes standard. Il est important de connaître la spécification des méthodes HTTP. Par exemple, GET signifie récupérer les informations identifiées par l'URL de la requête, DELETE signifie demander au serveur de supprimer la ressource identifiée par l'URL donnée, etc. Les codes de statut HTTP ont une spécification également, par exemple 200 signifie succès, 201 signifie qu'une nouvelle ressource a été créée, 404 signifie que la ressource demandée n'a pas été trouvée sur le serveur, etc ... L'utilisation des normes existantes est une partie importante. de repos.

  • Hypermedia en tant que moteur de l'état de l'application (HATEOAS ci-après) - Hypermedia est un type de média pouvant contenir des hyperliens. Sur le Web, nous suivons des liens - décrits par un format hypermédia (généralement HTML) - pour atteindre un objectif, au lieu de taper les URL dans la barre d'adresse. REST suit le même concept, les représentations envoyées par le service peuvent contenir des hyperliens. Nous utilisons ces hyperliens pour envoyer des demandes au service. Avec la réponse, nous obtenons des données (et probablement plus de liens) que nous pouvons utiliser pour construire le nouvel état du client, etc. C'est pourquoi l'hypermédia est le moteur de l'état de l'application (état du client). Vous vous demandez probablement comment les clients reconnaissent et suivent les hyperliens? Pour l’homme, c’est assez simple, nous lisons le titre du lien, remplissons peut-être des champs de saisie, puis un simple clic. Par machines, nous devons ajouter une sémantique aux liens avec RDF (par JSON-LD avec Hydra ) ou avec des solutions spécifiques à l’hypermédia (par exemple relations de liens IANA et Types MIME spécifiques au fournisseur par HAL + JSON ). Il existe de nombreux formats lisibles par machine XML et JSON , uniquement une courte liste d'entre eux:

    • XHTML
    • ATOME + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Siren
    • Collection + JSON

    Parfois, il est difficile de choisir ...

• Système en couches - Nous pouvons utiliser plusieurs couches entre les clients et les services. Aucun d'entre eux ne devrait connaître toutes ces couches supplémentaires, juste les couches juste à côté. Ces couches peuvent améliorer l'évolutivité en appliquant des caches et un équilibrage de charge ou peuvent appliquer des stratégies de sécurité.
• Code à la demande - Nous pouvons renvoyer un code qui étend les fonctionnalités du client, par exemple du code javascript à un navigateur. C'est la seule contrainte optionnelle de REST.

Webservice REST - SOAP Différences entre les services Web RPC

Ainsi, un _service web REST est très différent d'un webservice SOAP (avec un style de liaison RPC et un style d'encodage littéral)

• Il définit une interface uniforme (au sein d'un protocole).
• Il mappe les URL sur les ressources (et non sur les opérations).
• Il envoie des messages avec n'importe quel type MIME (au lieu de SOAP + XML).
• Il a une communication sans état et ne peut donc pas avoir de stockage de session côté serveur. (SOAP n'a pas de contrainte à ce sujet)
• Il sert hypermédia et les clients utilisent les liens contenus dans cet hypermédia pour demander le service. (RPC SOAP utilise les liaisons d'opération décrites dans le fichier WSDL)
• Il ne divise pas par les changements d'URL uniquement par les changements de sémantique. (Les clients SOAP RPC n'utilisant pas RDF, leur sémantique est interrompue par les modifications apportées au fichier WSDL.)
• Il évolue mieux qu'un service Web SOAP en raison de son comportement sans état.

etc...

Un service Web RPC SOAP ne respecte pas toutes les contraintes REST:

• architecture client-serveur - toujours
• sans état - possible
• cache - possible
• interface uniforme - jamais
• système en couches - jamais
• code à la demande (optionnel) - possible

Answer 8

Eh bien, je vais commencer par la deuxième question: Que sont les services Web? , pour des raisons évidentes.

Les WebServices sont essentiellement des éléments de logique (que vous pouvez vaguement qualifier de méthode) exposant certaines fonctionnalités ou données. Le client implémentant (techniquement parlant, consumant est le mot) a juste besoin de savoir quel est le (s) paramètre (s) que la méthode est va accepter et le type de données qu'il va retourner (si du tout, il fait).

Ce qui suit Link dit tout sur RESTE & SOAP d'une manière extrêmement lucide.

REST vs SOAP

Si vous voulez aussi savoir quand choisir quoi (REST ou SOAP), une raison de plus de le parcourir!

Answer 9

SOAP et REST font tous deux référence aux moyens permettant à différents systèmes de communiquer entre eux.

REST utilise pour cela des techniques qui ressemblent à la communication entre votre navigateur et les serveurs Web: utiliser GET pour demander une page Web, poster des champs de formulaire, etc.

SOAP fournit quelque chose de similaire mais fait tout en envoyant des blocs de XML dans les deux sens. Un autre composant clé de SOAP est WSDL, un document XML décrivant les fonctions et éléments de données pris en charge. Les WSDL peuvent être utilisés pour "découvrir" par programme les fonctions prises en charge, ainsi que pour générer des stubs de code de programmation.

Answer 10

REST est un style d'architecture pour la conception d'applications en réseau. L'idée est que, plutôt que d'utiliser des mécanismes complexes tels que CORBA, RPC ou SOAP pour se connecter entre des machines, un simple HTTP est utilisé pour effectuer des appels entre des machines.

Answer 11

Je pense que c'est aussi facile que je peux l'expliquer. S'il vous plaît, n'importe qui est le bienvenu pour me corriger ou ajouter à cela.

SOAP est un format de message utilisé par des systèmes déconnectés (comme sur Internet) pour échanger des informations/données. C'est le cas avec les messages XML qui vont et viennent.

Les services Web transmettent ou reçoivent SOAP messages. Ils travaillent différemment selon la langue dans laquelle ils sont écrits.

Answer 12

Le problème avec SOAP est qu'il est en conflit avec les idéaux situés derrière la pile HTTP. Tout middleware doit pouvoir travailler avec des requêtes HTTP sans comprendre le contenu de la requête ou de la réponse. Cependant, par exemple, un serveur de mise en cache HTTP classique ne fonctionnera pas avec les requêtes SOAP sans connaître uniquement les parties du fichier SOAP le contenu est important pour la mise en cache. SOAP utilise simplement HTTP comme enveloppe pour son propre protocole de communication, à la manière d'un proxy.

Answer 13

SOAP - "Protocole d'objet simple"

SOAP est un peu de transfert de messages, ou de petites quantités d'informations sur Internet. SOAP les messages sont formatés en XML et sont généralement envoyés contrôlant HTTP.

REST - "Transfert d'état représentatif"

REST est un procédé rudimentaire d’éventualité et de réception d’informations entre le ventilateur et le serveur et de nombreux standards ne sont pas clairement définis. Vous pouvez envoyer et accepter des informations en tant que JSON, XML ou même du texte brut. Il est léger comparé à SOAP.