Transfert d'état représentatif (REST) ​​et protocole d'accès aux objets simples (SOAP)


723

Quelqu'un peut-il expliquer ce qu'est REST et ce qu'est SOAP en anglais? Et comment fonctionnent les services Web?


5
Vous devez lire ce PDF pour comprendre les services Web REST et SOAP.
Lalit Kumar Maurya

2
Vous pouvez consulter ce blog javapapers.com/web-service/rest-vs-soap
spideringweb

1
Puis-je recommander de lire la dissertation de Fielding sur le sujet de REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Philip Couling


1
@PhilipCouling Je n'appellerais pas de thèse de doctorat en anglais simple ...
stt106

Réponses:


1590

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ésentatif

Le repos 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 du texte brut. Il est léger par rapport au SOAP.


entrez la description de l'image ici


73
SOAP, c'est bien plus que l'envoi de données dans une enveloppe. Cependant, il est principalement utilisé pour envoyer un BLOB au serveur, ignorant toutes les fonctionnalités fournies par SOAP. Donc, fondamentalement, la plupart des gens utilisent SOAP comme REST avec une enveloppe standard. (SOAP est un bon exemple de sur-ingénierie)
elmuerte

15
SOAP n'oblige en AUCUN CAS à utiliser HTTP ou XML. HTTP et XML sont les éléments définis dans WS-I pour l'interopérabilité, mais on peut également envoyer des POJO via JMS. Le truc c'est que le programmeur n'a pas besoin de s'en soucier: le bus de service gère le transport et l'encodage.
koppor

56
Pour chaque problème complexe, il existe une réponse claire, simple et erronée. --HL Mencken
jmh

5
L'exemple était épique!
Kaidul

18
CONTINUE DE LIRE. Bien que cette réponse soit divertissante, la réponse de @ Pavel ci-dessous est beaucoup plus complète.
Josh Johnson

323

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 c'est plus simple à utiliser et à comprendre.

Protocole d'accès aux objets simples (SOAP):

  • SOAP construit un protocole XML 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 manière standard de communiquer.
  • Plusieurs langages de programmation prennent en charge nativement SOAP, vous lui fournissez 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 encodées dans un format tel que encodé en base64.
  • Possède plusieurs protocoles et technologies s'y rapportant: WSDL, XSDs, SOAP, WS-Addressing

Transfert d'état représentatif (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, il dit attendre 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 placer une ressource sur le serveur, vous utilisez HTTP PUT. Pour supprimer une ressource sur le serveur, vous utilisez HTTP DELETE.
  • REST est très simple en ce qu'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 l' architecture orientée ressources (ROA). Dans ce mode de penser, tout est une ressource, et vous opérez sur ces ressources.
  • Tant que votre langage de programmation possède une bibliothèque HTTP, et la plupart le font, vous pouvez consommer un protocole HTTP REST très facilement.
  • Les données binaires ou les ressources binaires peuvent simplement être livrées à leur demande.

Il y a des 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, mais des copies peuvent être trouvées sur Wayback Machine ou en PDF sur CiteSeerX .


28
REST n'a rien à voir avec HTTP (il est indépendant du protocole), et XML est bien à utiliser dans une architecture RESTful. GET / POST / PUT / DELETE utilise simplement HTTP correctement - nécessaire pour REST mais pas suffisant.
aehlke

10
Comment le client REST peut-il savoir quelles méthodes et quels types il peut utiliser? Dans SOAP, il existe WSDL à partir duquel de nombreux outils peuvent générer des classes et des méthodes.
jlp

3
@jlp: Il appartient au développeur du client REST d'utiliser correctement l'interface REST exposée.
Brian R. Bondy

14
REST dit simplement «utiliser une interface uniforme». Depuis que l'interface HTTP [GET, POST, PUT, DELETE, (UPDATE, HEAD)] est devenue l '«interface uniforme» du Web, REST (sur le Web) dépend en quelque sorte de HTTP à mon avis!
Andre Schweighofer

3
@aehlke REST dépend TRÈS BEAUCOUP de HTTP. Dire le contraire est fou. L'approche REST est solidement définie via le HTTP RFC (par le W3C TAG). Il n'y a pas d'autre spécification autre qu'une thèse de doctorat par Roy Fielding de UC Irvine. Voir: en.wikipedia.org/wiki/Representational_state_transfer
Brenden

260

DU REPOS

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 vu à 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 des ordinateurs plutôt que des clients humains via notre application?' Combinez cela avec la puissance de l'infrastructure WWW et vous obtiendrez un outil de tueur pour créer de grandes applications distribuées.

Une autre explication possible est pour les gens qui pensent mathématiquement. Chaque application est essentiellement une machine à états dont les actions de logique métier sont des transitions d'état. L'idée de REST est de mapper chaque transition sur une demande à une ressource et de fournir aux clients des liens représentant les transitions disponibles dans l'état actuel. Il modélise ainsi la machine à états via des représentations et des liens. C'est pourquoi cela s'appelle REpresentational State Transfer.

Il est assez surprenant que toutes les réponses semblent se concentrer soit sur le format des messages, soit sur l'utilisation des verbes HTTP. En fait, le format du message n'a pas d'importance du tout, REST peut utiliser n'importe lequel à condition que le développeur du service le documente. Les verbes HTTP font uniquement d'un service un service CRUD, mais pas encore RESTful. Ce qui transforme vraiment un service en service REST, ce sont les liens hypertextes (également appelés contrôles hypermédia) intégrés dans les réponses du serveur avec les données, et leur montant doit être suffisant pour que tout client puisse choisir l'action suivante à partir de ces liens.

Malheureusement, il est assez difficile de trouver des informations correctes sur REST sur le Web, à l'exception de la thèse de Roy Fielding . (C'est lui qui a dérivé REST). Je recommanderais le livre «REST en pratique» car il donne un didacticiel complet étape par étape sur la façon de passer de SOAP à REST.

SAVON

Il s'agit de l'une des formes possibles de style d'architecture RPC (appel de procédure distante). En substance, c'est juste 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 en fait d'appeler des méthodes locales en termes de vitesse, de fiabilité, etc., mais l'idée est aussi simple que cela.

Par rapport

Les détails tels que les protocoles de transport, les formats de message, xsd, wsdl, etc. n'ont pas d'importance lors de la comparaison de toute forme de RPC à REST. La principale différence est qu'un service RPC réinvente le vélo en concevant son propre protocole d'application dans l'API RPC avec la sémantique que lui seul connaît. Par conséquent, tous les clients doivent comprendre ce protocole avant d'utiliser le service, et aucune infrastructure générique comme les caches ne peut être créée 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 de l'API et des contrôles hypermédia (liens) pour mettre en évidence les options disponibles dans chaque état. Donc,

D'une certaine manière, SOAP (comme tout autre RPC) est une tentative de tunnel à travers une limite de service traitant les médias de connexion comme une boîte noire capable de transmettre des messages uniquement. REST est une décision de reconnaître que le Web est un énorme système d'information distribué, d'accepter le monde tel qu'il est et d'apprendre à le maîtriser au lieu de lutter contre lui.

SOAP semble être idéal pour les API 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 pour les développeurs de l'utiliser. Cependant, pour une API publique qui est utilisée par de nombreuses parties indépendantes, est complexe et grande, REST devrait mieux s'adapter. Mais cette dernière comparaison est très floue.

Mise à jour

Mon expérience a montré de manière inattendue que le développement REST était plus difficile que SOAP. Au moins pour .NET. Bien qu'il existe d'excellents cadres comme l'API Web ASP.NET, aucun outil ne générerait automatiquement un proxy côté client. Rien de tel que «Ajouter une référence de service Web» ou «Ajouter une référence de service WCF». Il faut écrire à la main tout le code de requête de sérialisation et de service. Et l'homme, c'est beaucoup de code passe-partout. Je pense que le développement REST a besoin de quelque chose de similaire à WSDL et à l'implémentation d'outils pour chaque plate-forme de développement. En fait, il semble y avoir un bon terrain: WADL ou WSDL 2.0 , mais aucune des normes ne semble bien prise en charge.

Mise à jour (janvier 2016)

Il s'avère qu'il existe maintenant une grande variété d'outils pour la définition de l'API REST. Ma préférence personnelle est actuellement RAML .

Fonctionnement des services Web

Eh bien, c'est une question trop large, 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 qui peut accepter des demandes de clients et renvoyer des réponses. Il est exposé au Web, donc c'est un service Web , et il est généralement disponible 24/7, c'est pourquoi c'est un service . Bien sûr, cela résout un problème (sinon pourquoi quelqu'un utiliserait-il un service Web) pour ses clients.


45
Cela devrait être de loin la réponse la plus votée! J'ai le sens de l'humour, mais c'est déprimant quand la comédie répond sur StackOverflow comme bien réfléchie.
Tom W Hall

3
@TomHall Je suppose que cette situation est un peu spécifique à la discussion REST - RPC, pas seulement sur SO. Je suppose que c'est la raison pour laquelle nous n'avons pas d'outils raisonnables pour les clients REST. Au moins sur .NET, l'implémentation d'un client de service REST s'est avérée beaucoup plus difficile que de générer une référence de service SOAP. Il faut écrire les classes proxy à la main. Pour une raison quelconque, les gens pensent à REST comme s'il n'y avait pas de règles du tout, tandis que l'idée originale, au contraire, impose beaucoup plus de restrictions à l'architecture. Je souhaite que la communauté comprenne REST - alors nous pourrions nous attendre à de meilleurs outils et à une meilleure adoption.
Pavel Gatilov

2
@PavelGatilov Cette réponse est excellente. J'avais lu d'autres explications REST et je n'ai jamais "compris" que le principe de conduite est que les transitions d'état possibles font partie de la réponse. Le fait que vous ayez pris le temps de réfléchir à votre expérience et de reconnaître les difficultés est également d'une grande valeur pour chacun d'entre nous.

Excellente réponse. Je me demande combien de temps il faudra pour que REST-I se développe maintenant et commence à ressembler de plus en plus à SOAP, comme avec RAML, Swagger et WADL, le slogging pour la norme de facto d'être REST. J'ai trouvé le manque d'outils sur REST par rapport à SOAP une douleur majeure lors du développement de certains systèmes financiers plutôt sensibles et complexes. REST et SOAP sont géniaux lorsqu'ils sont utilisés correctement. Mon grand-père a toujours dit que vous pouvez utiliser un tournevis pour enfoncer un clou, mais cela ne fonctionnera pas aussi bien. Il en va de même ici. Le bon outil pour la mentalité de travail n'est pas mon chemin est le seul moyen. \
Namphibian

Oh, je suis également favorable à RAML et je préfère le développement descendant, la seule chose que j'ai trouvée la plus troublante à propos de REST était l'absence d'une approche structurée descendante. J'aime réfléchir avant d'agir.
Namphibian


38

SOAP - Simple Object Access Protocol est un protocole !

REST - REpresentational State Transfer est un style architectural !

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

RESTet ne SOAPsont sans doute pas mutuellement exclusifs. Une architecture RESTful peut utiliser HTTPou SOAPou un autre protocole de communication. RESTest optimisé pour le web et HTTPest donc un choix parfait. HTTPest également le seul protocole discuté dans l'article de Roy Fielding.

Bien que REST et SOAP soient clairement très différents, la question éclaire le fait que RESTetHTTP sont souvent utilisés en tandem. Cela est principalement dû à la simplicité de HTTP et à sa 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 distincte des préoccupations. Toutes les applications construites dans le style RESTful doivent également être client-serveur en principe.

Apatride

Chaque demande de chaque client au serveur nécessite que son état soit entièrement représenté. Le serveur doit être en mesure de comprendre complètement la demande du client sans utiliser de contexte de serveur ou d'état de session de serveur. Il s'ensuit que tout état doit être conservé sur le client. Nous discuterons plus en détail de la représentation des apatrides plus tard.

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 cachable. Toutes les données marquées comme pouvant être mises en cache peuvent être réutilisées 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 les 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 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 modifiant l'interface, vous n'avez pas de chance car REST l'interdit. Du côté positif, cependant, REST est optimisé pour le Web, d'où une popularité incroyable de REST sur HTTP!

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

Voir ce blog post sur Principals REST conception pour plus de détails sur REST et les points ci - dessus mentionnées.


Il suffit de penser qu'il serait totalement HATEOAS de demander une ressource RESTful et de recevoir une réponse qui inclut un lien vers WSDL décrivant les opérations disponibles sur cette ressource dans son état actuel. Bien que je suppose qu'un service Web RESTful SOAP serait un peu comme sauter le niveau 3 de RMM et aller directement au niveau 4. :)
Steve

3
C'est la meilleure réponse pour penser que ce n'est pas avec / ou avec REST et SOAP. +1 pour avoir noté que REST est un style .
ABMagil

12

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

REST est un échange d'informations sur l'état, aussi simple que possible.

SOAP est un protocole de message qui utilise 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ées. Voir wikipedia pour 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- *


SOAP n'est PAS un protocole. SOAP concerne l'encodage. SOAP est utilisé sur de nombreux protocoles: JMS, http, ...
koppor

16
@koppor Vous voulez dire autre que le fait qu'il signifie "Simple Object Access Protocol"? Savez-vous également ce qu'est un protocole? Un protocole est essentiellement un ensemble de règles sur la façon dont deux ou plusieurs choses doivent communiquer, ce qui est exactement à quoi sert SOAP, une façon standard de communiquer.
kyrias

4
@Demizey Vous référez-vous à la version la plus récente de SOAP, qui est 1.2? w3.org/TR/soap12-part1 "SOAP" est désormais autonome car en pratique il n'est PAS utilisé comme protocole. "SOAP 1.2 n'épellera pas l'acronyme." ( w3.org/TR/2007/REC-soap12-part0-20070427/#L4697 ) Connaissez -vous les couches de la pile de services Web comme (par exemple) décrites dans le livre "Architecture des plates-formes de services Web: Soap, Wsdl, Ws -Politique, Ws-Addressing, Ws-Bpel, Ws-Reliable Messaging, et plus "? La communication de la couche transport se fait via HTTP, SMTP, RMI / IIOP, JMS ou autres. SOAP est utilisé dans la couche de messagerie
koppor

Le long de la ligne d'une connexion SOAP, de nombreux intermédiaires peuvent s'asseoir entre les deux. Ceci est activé par le modèle de traitement SOAP, qui fait la distinction entre le récepteur SOAP ultime et zéro ou plusieurs intermédiaires SOAP. Le protocole de transport peut changer entre les deux. Le chemin du message SOAP permet également une implémentation transparente des modèles EAI ( eaipatterns.com )
koppor

12
C'est toujours un protocole de messagerie.
kyrias

7

Les services Web SOAP et les services Web REST peuvent également utiliser le protocole HTTP et d'autres protocoles (pour ne citer que SOAP peut être le protocole sous-jacent de REST). Je ne parlerai que des protocoles SOAP et REST liés au protocole HTTP, car c'est leur utilisation la plus fréquente.

SAVON

SOAP ("simple" object access protocol) est un protocole (et une norme W3C ). Il définit comment créer, envoyer et traiter des messages SOAP.

  • Les messages SOAP sont des documents XML avec une structure spécifique: ils contiennent une enveloppe qui contient l'en-tête et la section corps. Le corps contient les données réelles - que nous voulons envoyer - au format XML. Il existe deux styles d'encodage , mais nous choisissons généralement le 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 le sous-type SOAP + XML MIME. Ces messages HTTP peuvent être en plusieurs parties, nous pouvons donc éventuellement joindre des fichiers aux messages SOAP.

  • Évidemment, nous utilisons une architecture client-serveur, donc les clients SOAP envoient des requêtes aux webserices SOAP et les services renvoient des 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 que nous voulons envoyer et la liaison WSDL qui définit la façon dont le service Web est lié au protocole HTTP. Il y a deux styles de reliure: 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 (requêtes 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 qui est validé par rapport au XSD. Je pense que le style de liaison de document est mieux adapté aux systèmes basés sur des événements, mais je n'ai jamais utilisé ce style de liaison. Le style de liaison RPC est plus répandu, donc la plupart des gens utilisent SOAP à des fins XML / RPC par des applications distribuées. Les webservices se retrouvent généralement en demandant à un serveur UDDI . Les serveurs UDDI sont des registres qui stockent l'emplacement des services Web.

SOAP RPC

Donc, à mon avis, le service Web SOAP le plus répandu utilise le style de liaison RPC et le style de codage littéral et il a les propriétés suivantes:

  • Il mappe les URL aux opérations.
  • Il envoie des messages avec le sous-type SOAP + XML MIME.
  • Il peut avoir un magasin de sessions côté serveur, il n'y a aucune 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 se cassent par des changements d'interface (noms de méthode résultants et / ou changements de paramètres).
  • Il est possible d'écrire des clients SOAP qui ne se cassent pas par des changements d'interface en utilisant RDF et de trouver des opérations par sémantique, mais le webservice sémantique est très rare et ils n'ont pas nécessairement de client non cassant (je suppose).

DU REPOS

REST (representational state transfer) est un style d'architecture qui est décrit dans la thèse de Roy Fielding. Cela ne concerne pas les protocoles comme SOAP. Il commence par un style d'architecture null sans contraintes 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'y a pas de niveaux REST . Lorsqu'un service Web ne rencontre pas toutes les contraintes REST, il ne s'agit pas d'un service Web REST.

Contraintes REST

  • Client - architecture serveur - je pense que cette partie est familière à tout le monde. Les clients REST communiquent avec les webservices REST, les webservices conservent les données communes - l'état des ressources ci-après - et les servent aux clients.
  • Sans état - 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 ressource (qu'ils gèrent). Les requêtes n'ont donc pas de contexte, elles contiennent toujours les informations nécessaires pour les traiter. Par exemple, par l'authentification de base HTTP, le nom d'utilisateur et le mot de passe sont stockés par le client et il les envoie avec chaque demande, donc l'authentification se produit à chaque demande. Ceci est très différent des applications Web classiques où l'authentification ne se produit que par connexion. Nous pouvons utiliser n'importe quel mécanisme de stockage de données côté client comme en mémoire (javascript), cookies, localStorage, etc. pour conserver certaines parties de l'état du client si nous le voulons. La raison de la contrainte de l'apatridie, c'est que le serveur évolue bien - même par très forte charge (millions d'utilisateurs) - lorsqu'il n'a pas à maintenir la session de chaque client.
  • Cache - La réponse doit contenir des informations à ce sujet qui peuvent être mises en cache par le client ou non. Cela améliore encore l'évolutivité.
  • Interface uniforme

    • Identification des ressources - La ressource REST est identique à la ressource RDF . Selon Fielding, si vous pouvez nommer quelque chose, cela peut être une ressource, par exemple: "la météo locale actuelle" peut être une ressource, ou "votre téléphone portable" peut être une ressource, ou "un document Web spécifique" peut être une ressource. Pour identifier une ressource, vous pouvez utiliser des identifiants de ressource: URL et URN (par exemple le numéro ISBN par les livres ). Un identifiant unique ne doit appartenir qu'à une ressource spécifique, mais une seule ressource peut avoir de nombreux identifiants, que nous exploitons fréquemment par exemple par pagination avec des URL commehttps://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. Ce sont les bases de la création d'URL par REST. Btw. la structure URL n'a d'importance que pour les développeurs de services, un vrai client REST ne s'en soucie 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 le versionnage classique à 3 chiffres et n'ajouter que le numéro principal aux URL (https://example.com/api/v1/). Donc, par des modifications rétrocompatibles, rien ne se passe, par des modifications non rétrocompatibles, vous aurez une sémantique non rétrocompatible avec une nouvelle racine API https://example.com/api/v2/. Ainsi, les anciens clients ne se casseront pas, car ils peuvent utiliser le https://example.com/api/v1/avec l'ancienne sémantique.
    • Manipulation des ressources via des représentations - Vous pouvez manipuler les données liées aux ressources (état des ressources) en envoyant la représentation voulue des ressources - ainsi que la méthode HTTP et l'identifiant de ressource - au service REST. Par exemple, si vous souhaitez renommer un utilisateur après le mariage, vous pouvez envoyer une PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}demande où {name: "Mrs Smith"}est une représentation JSON de l'état de ressource prévu, en d'autres termes: le nouveau nom. Cela se produit vica-versa, 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 GET https://example.com/api/v1/users/1?fields="name"demande de récupération, qui se traduit par un200 ok, {name: "Mrs Smith"}réponse. Nous pouvons donc utiliser cette représentation pour changer l'état du client, par exemple, nous pouvons afficher un "Bienvenue sur notre page Mme Smith!" message. Une ressource peut avoir de nombreuses représentations en fonction de l'identifiant de ressource (URL) ou de l'en- accepttête que nous avons envoyé avec la demande. Par exemple, nous pouvons envoyer une image de Mme Smith (probablement pas nue) si elle image/jpegest demandée.
    • Messages auto-descriptifs - Les messages doivent contenir des informations sur la façon 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 des informations identifiées par l'URL de demande, DELETE signifie demander au serveur de supprimer la ressource identifiée par l'URL donnée, et ainsi de suite ... Les codes d'état HTTP ont également une spécification , par exemple 200 signifie succès, 201 signifie 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 standards existants est une partie importante de REST.
    • Hypermedia comme moteur de l'état de l'application (HATEOAS ci-après) - Hypermedia est un type de média qui peut 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 créer le nouvel état client, et ainsi de suite ... C'est pourquoi l'hypermédia est le moteur de l'état de l'application (état client). Vous vous demandez probablement comment les clients reconnaissent et suivent les hyperliens? Par les humains, c'est assez simple, nous lisons le titre du lien, remplissons peut-être les champs de saisie, puis après un simple clic.JSON-LD avec Hydra ) ou avec des solutions spécifiques à l'hypermédia (par exemple les relations de liaison IANA et les types MIME spécifiques au fournisseur par HAL + JSON ). Il existe de nombreux formats hypermédia XML et JSON lisibles par machine , juste une courte liste d'entre eux:

      Parfois, c'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 la couche juste à côté. Ces couches peuvent améliorer l'évolutivité en appliquant des caches et un équilibrage de charge ou elles peuvent appliquer des politiques de sécurité.
  • Code à la demande - Nous pouvons renvoyer du code qui étend les fonctionnalités du client, par exemple du code javascript à un navigateur. Il s'agit de la seule contrainte facultative de REST.

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

Un service Web REST est donc très différent d'un service Web SOAP (avec un style de liaison RPC et un style de codage littéral)

  • Il définit une interface uniforme (au lieu d'un protocole).
  • Il mappe les URL aux ressources (et non aux opérations).
  • Il envoie des messages avec tous les types MIME (au lieu de simplement SOAP + XML).
  • Il a une communication sans état et ne peut donc pas avoir de stockage de session côté serveur. (SOAP n'a aucune contrainte à ce sujet)
  • Il sert l'hypermédia et les clients utilisent les liens contenus dans cette hypermédia pour demander le service. (SOAP RPC utilise les liaisons d'opération décrites dans le fichier WSDL)
  • Il ne se casse pas par des changements d'URL seulement par des changements de sémantique. (Les clients SOAP RPC sans utiliser la sémantique RDF sont interrompus par les modifications du fichier WSDL.)
  • Il évolue mieux qu'un service Web SOAP en raison de son comportement sans état.

etc...

Un service Web SOAP RPC ne répond pas à toutes les contraintes REST:

  • architecture client-serveur - toujours
  • apatride - possible
  • cache - possible
  • interface uniforme - jamais
  • système en couches - jamais
  • code sur demande (facultatif) - possible

6

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 appeler une méthode) qui exposent certaines fonctionnalités ou données. Le client implémentant (techniquement parlant, consommer est le mot) a juste besoin de savoir quels sont les paramètres de la méthode va accepter et le type de données qu'elle va retourner (si c'est le cas).

Le lien suivant en dit long sur REST & SOAP d'une manière extrêmement lucide.

REST vs SOAP

Si vous voulez aussi savoir quand choisir quoi (REST ou SAVON), raison de plus pour y passer!


5

SOAP et REST se réfèrent tous deux à des façons pour différents systèmes de communiquer entre eux.

REST le fait en utilisant des techniques qui ressemblent à la communication que votre navigateur a avec les serveurs Web: utiliser GET pour demander une page Web, POSTER dans 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 qui est un document XML qui décrit quelles fonctions et éléments de données sont 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.


1
Cela n'a rien à voir avec REST, c'est juste une `` utilisation correcte de HTTP ''
aehlke

HTTP lui-même est le meilleur exemple d'un système RESTful.
pbreitenbach

1
@pbreitenbach Non, HTTP ne l'est pas, il n'a fondamentalement aucune notion d'hypermédia. Mais le HTML avec ses hyperliens et ses formulaires est un système RESTful. En fait, c'était le prototype de la «spécification» REST
Pavel Gatilov

SOAP ne vous oblige PAS à utiliser le codage XML. L'encodage XML n'est utilisé que si un service offre une interopérabilité. En interne, les POJO peuvent être envoyés sans encodage en XML.
koppor

2

Je pense que c'est aussi simple 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 les systèmes déconnectés (comme sur Internet) pour échanger des informations / données. Il le fait avec des messages XML qui vont et viennent.

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


Expliquez ce que vous entendez par «ils fonctionnent différemment». SOAP est généralement utilisé comme moyen pour différents systèmes écrits dans des technologies différentes ou inconnues de parler en utilisant un langage compréhensible commun avec des paramètres clairement définis.
MyItchyChin

Les services Web fonctionnent différemment selon la langue dans laquelle ils sont écrits. Juste un détail supplémentaire sans importance.
StingyJack

D'accord, je ne savais pas si vous laissiez entendre qu'il y avait quelque chose qui empêchait l'interopérabilité.
MyItchyChin

2

Le problème avec SOAP est qu'il est en conflit avec les idéaux derrière la pile HTTP. Tout middleware doit pouvoir travailler avec les requêtes HTTP sans comprendre le contenu de la requête ou de la réponse, mais par exemple, un serveur de mise en cache HTTP normal ne fonctionnera pas avec les requêtes SOAP sans savoir uniquement quelles parties du contenu SOAP sont importantes pour la mise en cache. SOAP utilise simplement HTTP comme enveloppe pour son propre protocole de communication, comme un proxy.


2
C'est contre les idéaux, et nous venons juste de le remarquer. Il existe depuis 1998 environ, et nous ne faisons que le reprendre. Merde, nous sommes stupides!
John Saunders, le

Non John, "nous" en tant que communauté de développeurs Web avertis, ne l'avons jamais su. Ce ne sont que les plus lents et ceux qui sortent de l'école CS sans une éducation appropriée qui viennent de s'accommoder.
Nicholas Shanks

"Nous" ne sommes pas tous des développeurs Web. Certains d'entre nous essaient simplement de faire avancer les choses de la meilleure façon possible et ne se soucient pas si nous «n'utilisons pas le plein potentiel du Web».
John Saunders

"stupide" résume à peu près tout, oui.
Rob Grant

2

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 machines, un simple HTTP est utilisé pour effectuer des appels entre machines.


1

SOAP - "Simple Object Access Protocol"

SOAP est un léger 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 en contrôlant HTTP .

REST - "REpresentational State Transfer"

REST est un processus rudimentaire d'éventualité et de réception d'informations entre le ventilateur et le serveur et il n'a pas défini de nombreuses normes sans équivoque. Vous pouvez envoyer et accepter des informations au format JSON , XML ou même du texte brut. Il est léger par rapport au SOAP .


-4

Services Web basés sur SOAP En bref, le modèle des services basés sur SOAP considère le monde comme un écosystème de pairs égaux qui ne peuvent pas se contrôler, mais doivent travailler ensemble en respectant les contrats publiés. C'est un modèle valide du monde réel désordonné, et les contrats basés sur les métadonnées forment l'interface de service SOAP.

nous pouvons toujours associer SOAP aux appels de procédure à distance basés sur XML, mais la technologie des services Web basés sur SOAP est devenue un modèle de messagerie flexible et puissant.

SOAP suppose que tous les systèmes sont indépendants et qu'aucun système n'a la moindre connaissance des fonctions internes d'une autre fonctionnalité interne. La plupart de ces systèmes peuvent faire est de s’envoyer des messages et d’espérer qu’ils seront traités. Les systèmes publient des contrats qu'ils s'engagent à honorer et d'autres systèmes s'appuient sur ces contrats pour échanger des messages avec eux.

Les contrats entre les systèmes sont collectivement appelés métadonnées et comprennent des descriptions de service, les modèles d'échange de messages pris en charge et les politiques régissant les qualités de service (un service peut devoir être chiffré, fourni de manière fiable, etc.) Une description de service, à son tour, est une description détaillée spécification des données (documents de message) qui seront envoyées et reçues par le système. Les documents sont décrits à l'aide d'un langage de description XML comme la définition de schéma XML. Tant que tous les systèmes respectent leurs contrats publiés, ils peuvent interopérer et les modifications apportées aux composants internes des systèmes n'affectent aucun autre. Chaque système est responsable de la traduction de ses propres implémentations internes vers et depuis ses contrats

REST - Transfert d'état représentatif. Le protocole physique est HTTP. Fondamentalement, REST signifie que toutes les ressources distinctes du Web sont identifiables de manière unique par une URL. Toutes les opérations qui peuvent être effectuées sur ces ressources peuvent être décrites par un ensemble limité de verbes (les verbes «CRUD») qui à leur tour sont mappés aux verbes HTTP.

Les REST sont beaucoup moins «lourds» que SOAP.

Fonctionnement du service web


2
-1 Presque tout ce que vous dites est incorrect. SOAP ne contient pas de description. Le WSDL le fait. WSDL est un format XML - il ne "s'exécute" sur aucun protocole. SOAP ne nécessite pas de middleware. REST n'est pas "la deuxième génération de services Web". WADL n'est pas une norme. Voir en.wikipedia.org/wiki/Web_Application_Description_Language .
John Saunders
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.