Quelqu'un peut-il expliquer ce qu'est REST et ce qu'est SOAP en anglais? Et comment fonctionnent les services Web?
Quelqu'un peut-il expliquer ce qu'est REST et ce qu'est SOAP en anglais? Et comment fonctionnent les services Web?
Réponses:
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.
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):
Transfert d'état représentatif (REST):
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 .
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.
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 au sujet de REST, en termes simples profanes. Doit lire!
comment-je-ai-expliqué-le-repos-à-ma-femme (lien original)
comment-j'ai-expliqué-le-repos-à-ma-femme (lien de travail 2013-07-19)
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
REST
et ne SOAP
sont sans doute pas mutuellement exclusifs. Une architecture RESTful peut utiliser HTTP
ou SOAP
ou un autre protocole de communication. REST
est optimisé pour le web et HTTP
est donc un choix parfait. HTTP
est é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 REST
etHTTP
sont souvent utilisés en tandem. Cela est principalement dû à la simplicité de HTTP et à sa correspondance très naturelle avec les principes RESTful.
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.
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- *
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.
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.
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:
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.
Interface uniforme
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. 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.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- accept
tête que nous avons envoyé avec la demande. Par exemple, nous pouvons envoyer une image de Mme Smith (probablement pas nue) si elle image/jpeg
est demandée.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 ...
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)
etc...
Un service Web SOAP RPC ne répond pas à toutes les contraintes REST:
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.
Si vous voulez aussi savoir quand choisir quoi (REST ou SAVON), raison de plus pour y passer!
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.
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.
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.
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 .
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.