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

Question

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

Answer 1

Explication simple de SOAP et REST

SOAP - "Simple Object Access Protocol" (protocole d'accès aux objets simples)

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

---

Rest - Representational state transfer

Rest est un moyen simple d'envoyer et de recevoir des données entre un client et un serveur et il n'y a pas beaucoup de normes définies. Vous pouvez envoyer et recevoir des données sous forme de JSON, XML ou même de texte brut. Il est plus léger que SOAP.

---

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 va à REST car elle est plus simple à utiliser et à comprendre.

SOAP :

• SOAP construit un protocole XML au-dessus de HTTP ou parfois de TCP/IP.
• SOAP décrit les fonctions et les types de données.
• SOAP est le successeur de XML-RPC et est très similaire, mais décrit une manière standard de communiquer.
• Plusieurs langages de programmation ont un support natif pour 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 qui sont envoyées doivent d'abord être encodées dans un format tel que l'encodage base64.
• Plusieurs protocoles et technologies y sont associés : 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 penchant pour HTTP.
• REST est très léger, il dit "attendez une minute, nous n'avons pas besoin de toute cette complexité que SOAP a créée".
• 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, on utilise HTTP DELETE.
• REST est très simple en ce sens qu'il utilise les méthodes HTTP GET, POST et PUT pour mettre à jour les ressources sur le serveur.
• En général, REST est utilisé de préférence avec l'architecture orientée ressources (ROA). Dans ce mode de pensée, tout est une ressource, et vous opérez sur ces ressources.
• Tant que votre langage de programmation dispose d'une bibliothèque HTTP, ce qui est le cas de la plupart d'entre eux, vous pouvez consommer un protocole REST HTTP très facilement.
• Les données binaires ou les ressources binaires peuvent simplement être livrées à leur demande.

Il y a des débats interminables 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 avoir été mis hors ligne et cet article n'est plus disponible, des copies peuvent cependant être trouvées sur le site de l'association. La machine à remonter le temps ou en format PDF à CiteSeerX .

Answer 3

REST

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 principaux moyens d'interaction avec 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 diriger des clients informatiques plutôt que des clients humains à travers notre application" ? Combinez cela avec la puissance de l'infrastructure WWW et vous obtiendrez un outil formidable pour créer de superbes applications distribuées.

Une autre explication possible concerne les personnes ayant une pensée mathématique. Chaque application est fondamentalement une machine à état, les actions de la logique commerciale étant des transitions d'état. L'idée de REST est de faire correspondre chaque transition à une requête vers une ressource et de fournir aux clients des liens représentant les transitions disponibles dans l'état actuel. Ainsi, il modélise la machine à états via des représentations et des liens. C'est pourquoi on l'appelle REpresentational State Transfer.

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 aucune importance, REST peut utiliser n'importe quel format à condition que le développeur du service le documente. Les verbes HTTP font seulement d'un service un service CRUD, mais pas encore RESTful. Ce qui fait réellement d'un service un service REST, ce sont les hyperliens (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 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 l'outil La thèse de Roy Fielding . (C'est lui qui a créé REST). Je recommande le Livre "REST in Practice car il donne un tutoriel complet, é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 (remote procedure call). En substance, il s'agit simplement d'une technologie qui permet aux clients d'appeler les méthodes du serveur via les frontières de service (réseau, processus, etc.) comme s'ils appelaient des méthodes locales. Bien sûr, cette technologie diffère de l'appel de méthodes locales en termes de vitesse, de fiabilité et autres, 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. n'ont pas d'importance lorsqu'on compare une 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 une 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 comme les caches ne peut être construite en raison de la sémantique propriétaire de toutes les demandes. En outre, les API RPC ne suggèrent pas quelles actions sont autorisées dans l'état actuel, ce qui doit être déduit d'une documentation supplémentaire. REST, en revanche, implique l'utilisation d'interfaces uniformes pour permettre aux différents clients d'avoir une certaine compréhension de la sémantique de l'API, et des contrôles hypermédias (liens) pour mettre en évidence les options disponibles dans chaque état. Ainsi, il est possible de mettre en cache les réponses aux services d'échelle et de découvrir facilement l'utilisation correcte de l'API sans documentation supplémentaire.

D'une certaine manière, SOAP (comme tout autre RPC) est une tentative de tunnellisation à travers la frontière d'un service en traitant le média de connexion comme une boîte noire capable de transmettre uniquement 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 qu'il est et d'apprendre à le maîtriser au lieu de le combattre.

SOAP semble être idéal pour les API de réseaux 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. En revanche, pour une API publique utilisée par de nombreuses parties indépendantes, complexe et de grande taille, REST devrait mieux convenir. 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 est plus difficile que SOAP. Du moins pour .NET. Bien qu'il existe d'excellents frameworks comme ASP.NET Web API, il n'existe aucun outil permettant de générer automatiquement un proxy côté client. Rien de tel que "Add Web Service Reference" ou "Add WCF Service Reference". Il faut écrire tout le code de sérialisation et d'interrogation du service à la main. Et bon sang, cela fait beaucoup de code passe-partout. Je pense que le développement REST a besoin de quelque chose de similaire à WSDL et de la mise en œuvre d'outils pour chaque plate-forme de développement. En fait, il semble y avoir un bon terrain : WADL o WSDL 2.0 mais aucune de ces normes ne semble être bien étayée.

Comment fonctionnent les services Web

C'est une question trop vaste, car elle dépend de l'architecture et de la technologie utilisées dans le service web en question. Mais en général, un service Web est simplement une application sur le Web qui peut accepter des demandes de clients et renvoyer des réponses. Il est exposé au Web, c'est donc un service Web. web et il est généralement disponible 24 heures sur 24, 7 jours sur 7. service . Bien sûr, il résout un problème (sinon pourquoi utiliser un service web) pour ses clients.

Answer 4

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

Cet article est un récit de mari à femme, où le mari explique à sa femme ce qu'est REST, en termes purement profanes. À lire absolument !

comment-j'ai-expliqué-le-repos-à-ma-femme (lien original)
comment-j'ai-expliqué-le-repos-à-ma-femme (2013-07-19 lien fonctionnel)

Answer 5

SOAP - Protocole d'accès simple aux objets es 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 n'est pas lié à un protocole spécifique. Vous pouvez mettre en œuvre une API RESTful en utilisant SOAP comme protocole.

REST, qui utilise HTTP, est devenu très populaire. Cela est dû en partie à la nature très légère de HTTP et à la correspondance très naturelle qui existe entre les méthodes HTTP et les opérations CRUD. Par exemple, lorsque vous créez une API RESTful à l'aide de HTTP, vous pouvez en vrac Pensez à vos opérations CRUD (Create, Retrieve, Update, Delete) comme étant le HTTP POST , GET , PUT y DELETE respectivement.

Plus important encore, REST a également de très belles caractéristiques :

• Tout est une ressource !
• Les ressources exposent une interface standard, par exemple POST , GET , DELETE , PUT lorsqu'il est utilisé avec des opérations HTTP Les opérations REST (en fonction de l'opération) présentent des caractéristiques spéciales, par exemple, sûres, idempotentes et/ou pouvant être mises en cache (voir l'article suivant). poste pour plus de détails)
• Les ressources sont liées
• Représentations multiples, par exemple XML, JSON, RDF
• La communication est apatride

Voir ceci article de blog en Principes de conception REST pour plus de détails sur REST et les points mentionnés ci-dessus.