Question Transfert d'état représentationnel (REST) ​​et protocole SOAP (Simple Object Access Protocol)


Quelqu'un peut-il expliquer ce qui est DU REPOS et qu'est-ce qui est SAVON en anglais? Et comment fonctionnent les services Web?


700
2017-10-16 19:24


origine


Réponses:


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

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 en texte brut. Il est léger comparé à SOAP.


enter image description here


1566
2018-01-24 07:02



Les deux méthodes sont utilisées par de nombreux grands joueurs. C'est une question de préférence. Ma préférence est REST parce que c'est plus simple à utiliser et à comprendre.

SOAP (Simple Object Access Protocol):

  • 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 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, XSDs, 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, il dit attendre une minute, nous n'avons pas besoin de toute la complexité que SOAP a créé.
  • 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 vous utilisez HTTP GET, pour mettre 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 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 l'architecture orientée ressources (ROA). Dans ce mode de pensée, tout est une ressource, et vous opéreriez sur ces ressources.
  • Tant que votre langage de programmation a une bibliothèque HTTP, et la plupart le font, vous pouvez utiliser un protocole HTTP REST très facilement.
  • Les données binaires ou les ressources binaires peuvent simplement être fournies à leur demande.

Il y a débats interminables sur REST vs SOAP sur google.

Mon préféré est celui-ci. Mise à jour 27 Nov 2013: le site de Paul Prescod semble être déconnecté et cet article n'est plus disponible, des exemplaires peuvent être trouvés sur le Machine à Wayback ou en PDF à CiteSeerX.


313
2017-10-16 19:33



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 constaté à quel point les sites Web sont faciles, flexibles, performants, etc. Les sites HTML utilisent des hyperliens et des formulaires comme moyen principal d'interaction de l'utilisateur. Leur objectif principal est de nous permettre, à nous, clients, de ne connaître que les liens que nous peut utiliser dans l'état actuel. Et REST dit simplement «pourquoi ne pas utiliser les mêmes principes pour piloter l'ordinateur plutôt que les clients humains grâce à notre application? Combinez cela avec la puissance de l'infrastructure WWW et vous obtiendrez un outil de tueur pour construire de superbes applications distribuées.

Une autre explication possible est de penser mathématiquement aux gens. Chaque application est fondamentalement une machine d'état avec des actions de logique métier étant des transitions d'état. L'idée de REST est de mapper chaque transition sur une requête à une ressource et fournir aux clients des liens représentant des transitions disponibles dans l'état actuel. Ainsi, il modélise la machine d'état via des représentations et des liens. C'est pourquoi il 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, REST peut utiliser n'importe lequel à condition que le développeur du service le documente. Les verbes HTTP ne font qu'un service un service CRUD, mais pas encore RESTful. Ce qui transforme un service en service REST, ce sont des liens hypertextes (également appelés contrôles hypermédia) intégrés dans les réponses du serveur avec les données, et leur quantité doit être suffisante pour que les clients choisissent l'action suivante à partir de ces liens.

Malheureusement, il est plutôt difficile de trouver des informations correctes sur REST sur le Web, à l'exception du La thèse de Roy Fielding. (Il est celui qui a dérivé REST). Je recommanderais le Le livre 'REST in Practice' car il donne un tutoriel détaillé étape par étape sur la façon d'évoluer de SOAP à REST.

SAVON

C'est l'une des formes possibles du style d'architecture RPC (Remote Procedure Call). Pour l'essentiel, il s'agit simplement d'une technologie qui permet aux clients d'appeler les méthodes du serveur via les limites de service (réseau, processus, etc.) comme s'ils appelaient des méthodes locales. Bien sûr, il diffère de l'appel des méthodes locales en vitesse, fiabilité, etc., mais l'idée est simple.

Par rapport

Les détails comme les protocoles de transport, les formats de message, xsd, wsdl, etc. n'ont pas d'importance quand on compare n'importe quelle 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 seul lui 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 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. Par ailleurs, REST implique d'utiliser des interfaces uniformes pour permettre à divers clients d'avoir une certaine compréhension de la sémantique API et des 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 aux services de mise à l'échelle et de rendre l'utilisation de l'API correcte facilement détectable sans documentation supplémentaire.

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

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 grand, REST devrait mieux s'adapter. Mais cette dernière comparaison est très floue.

Mettre à jour

Mon expérience a montré de manière inattendue que le développement REST était plus difficile que le SOAP. Au moins pour .NET. Bien qu'il existe de très bons frameworks comme ASP.NET Web API, il n'y a pas d'outils qui génèreraient 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'. On doit écrire tout le code de sérialisation et d'interrogation de service à la main. Et mec, c'est beaucoup de code standard. Je pense que le développement REST a besoin de quelque chose de similaire à WSDL et à l'implémentation de l'outillage 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 être bien soutenue.

Mise à jour (Jan 2016)

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

Comment fonctionnent les services Web

Eh bien, c'est une question trop large, car elle dépend de l'architecture et de la technologie utilisée dans le service Web spécifique. Mais en général, un service Web est simplement une application sur le Web qui peut accepter les demandes des clients et retourner les réponses. Il est exposé au Web, donc c'est un web service, et il est généralement disponible 24/7, c'est pourquoi c'est un un service. Bien sûr, cela résout certains problèmes (sinon pourquoi quelqu'un utiliserait-il un service web) pour ses clients?


239
2017-09-19 18:41



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

Cet article prend un récit de mari à femme, où le mari explique à sa femme à propos de REST, en termes purement profanes. Doit lire!

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


38
2017-07-13 07:33



SOAP - Simple Object Access Protocol est un protocole!

REST - 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 discutablement  ne pas mutuellement exclusif. Une architecture RESTful pourrait utiliser HTTP ou SOAP ou un autre protocole de communication. REST est optimisé pour le web et donc HTTP est un choix parfait. HTTP est aussi le seulement protocole discuté dans l'article de Roy Fielding.

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

Apatride

Chaque demande de chaque 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. Nous discuterons de la représentation des apatrides plus en détail plus tard.

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 Design Principals pour plus de détails sur DU REPOS et les balles mentionnées ci-dessus.


36
2018-03-14 20:28



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

REST est un échange d'informations d'état, fait aussi simplement 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 standards WS- * (appelés WS splat) associés aux services Web basés sur SOAP sont EXTREMEMENT compliqués. Voir Wikipédia 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-*


12
2017-10-16 19:47



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

SAVON

SAVON ("simple" objet protocole d'accès) est un protocole (et un W3C standard). Il définit comment créer, envoyer et traiter les 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 body. Le corps contient les données réelles - nous voulons envoyer - dans un format XML. Il y a deux styles d'encodage, mais nous choisissons généralement littérale, 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 sous forme de messages HTTP avec le sous-type MIME SOAP + XML. Ces messages HTTP peuvent être multipart, donc en option nous pouvons 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 envoient 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 comment le service Web est lié au protocole HTTP. Il y a 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 (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 à la XSD. Je pense que le style de liaison de documents est mieux adapté aux systèmes basés sur les é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 trouvent généralement en demandant UDDI serveur. Les serveurs UDDI sont des registres qui stockent l'emplacement des services Web.

SOAP RPC

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

  • Il mappe les URL aux opérations.
  • Il envoie des messages avec sous-type SOAP + XML MIME.
  • Il peut avoir un magasin de session côté serveur, il n'y a pas de contraintes à ce sujet.
  • Les pilotes client 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. La plupart des clients SOAP se brisent donc par des changements d'interface (noms de méthodes résultants et / ou changements de paramètres).
  • Il est possible d'écrire des clients SOAP qui ne se briseront pas par des changements d'interface en utilisant RDF et trouveront des opérations par sémantique, mais webservice sémantique sont très rares et ils n'ont pas nécessairement un client non cassant (je suppose).

DU REPOS

REST (transfert d'état représentationnel) est un style d'architecture décrit dans le thèse de Roy Fielding. Cela ne concerne pas les protocoles comme le fait SOAP. Il commence par un style d'architecture nul n'ayant pas de 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 rien de tel que Niveaux REST. Lorsqu'un service Web ne rencontre pas toutes les contraintes REST, il ne s'agit pas d'un service Web REST.

Les 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, les services Web conservent les données communes - état des ressources ci-après - et les fournissent aux clients.
  • Stateless - La partie "transfert d'état" de l'abréviation: REST. Les clients conservent l'état du client (état session / application), de sorte que les services ne doivent pas avoir de stockage de session. Les clients transfèrent la partie pertinente de l'état du client par chaque requête aux services qui répondent avec la partie pertinente de l'état de la ressource (gérée par eux). Les requêtes n'ont donc pas de contexte, elles contiennent toujours les informations nécessaires pour les traiter. Par exemple, par HTTP basic auth le nom d'utilisateur et le mot de passe sont stockés par le client, et il les envoie avec chaque requête, de sorte que l'authentification se produit à chaque requête. Ceci est très différent des applications web régulières où l'authentification se fait uniquement 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, localStorage, et ainsi de suite ... pour persister certaines parties de l'état du client si nous voulons. La raison de la contrainte d'apatridie, c'est que le serveur s'adapte bien - même par une charge très élevée (des millions d'utilisateurs) - quand il n'a pas à maintenir la session de chaque client.
  • Cache - La réponse doit contenir des informations à ce sujet peut être mis en cache par le client ou non. Cela améliore encore l'évolutivité.
  • Interface uniforme

    • Identification des ressources - la ressource REST est la même que RDF Ressource. Selon Fielding, si vous pouvez nommer quelque chose, alors cela peut être 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 identifiants de ressources: URL et URN (par exemple Numéro ISBN par livres). Un identifiant unique ne doit appartenir qu'à une ressource spécifique, mais une seule ressource peut avoir plusieurs identifiants, que nous exploitons fréquemment par pagination avec des URL comme https://example.com/api/v1/users?offset=50&count=25. Les URL ont quelques Caractéristiquespar exemple, les URL avec les mêmes chemins mais les 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 d'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 celle des versions 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 classique 3 versions de numéros et ajoutez seulement le nombre majeur aux URLs (https://example.com/api/v1/). Ainsi, rien ne se passe par des modifications rétrocompatibles. Par des 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 se cassent pas, car ils peuvent utiliser le https://example.com/api/v1/ avec l'ancienne sémantique.
    • Manipulation de 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 - avec la méthode HTTP et l'identificateur de ressource - au service REST. Par exemple, si vous voulez renommer un utilisateur après le mariage, vous pouvez envoyer un PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} demander où le {name: "Mrs Smith"} est une représentation JSON de l'état de la ressource prévue, en d'autres termes: le nouveau nom. Cela se passe 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 un GET https://example.com/api/v1/users/1?fields="name" demande de récupération, ce qui entraîne une 200 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 plusieurs représentations en fonction de l'identifiant de la ressource (URL) ou du accept En-tête 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 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 le 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 un spécification ainsi, 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 de 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. Par le Web, nous suivons les 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 liens hypertexte 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, et ainsi de suite ... C'est pourquoi 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, peut-être remplir les champs de saisie, et après cela, un simple clic. Par les machines, nous devons ajouter de la sémantique aux liens avec RDF (par JSON-LD avec Hydre) ou avec des solutions spécifiques hypermédia (par exemple Relations de l'IANA et types MIME spécifiques au fournisseur par HAL + JSON). Il y a beaucoup de machines à lire XML et Formats hypermédia JSON, juste une courte liste d'entre eux:

      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 additionnelles, juste de la couche juste à côté. Ces couches peuvent améliorer l'évolutivité en appliquant des caches et l'équilibrage de charge ou elles peuvent appliquer des stratégies 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. C'est la seule contrainte optionnelle de REST.

Webservice REST - Différences de service Web SOAP RPC

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

  • Il définit une interface uniforme (intead 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 seulement 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 hypermédia et les clients utilisent les liens contenus par cet hypermédia pour demander le service. (SOAP RPC utilise les liaisons d'opérations décrites dans le fichier WSDL)
  • Il ne rompt pas avec les changements d'URL uniquement par les changements de sémantique. (Les clients RPC SOAP sans utiliser la sémantique RDF se cassent par les changements de 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
  • apatride - possible
  • cache - possible
  • interface uniforme - jamais
  • système en couches - jamais
  • code sur demande (facultatif) - possible

7
2017-09-07 03:42