Pourquoi utiliser REST au lieu de services basés sur SOAP? [fermé]


153

J'ai assisté à une démo intéressante sur REST aujourd'hui, cependant, je ne pouvais pas penser à une seule raison (et aucune n'a été présentée) pour laquelle REST est de toute façon meilleur ou plus simple à utiliser et à implémenter qu'une pile de services SOAP.

Quelles sont certaines des raisons pour lesquelles quiconque dans le «monde réel» utilise REST au lieu des services basés sur SOAP?


37
Par services Web, faites-vous référence aux services Web de style SOAP? Parce que pour autant que je sache, vous pouvez également avoir des services Web RESTful.
James McMahon

Réponses:


160

Moins de frais généraux (pas d'enveloppe SOAP pour encapsuler chaque appel)

Moins de duplication (HTTP représente déjà des opérations comme DELETE, PUT, GET, etc. qui doivent autrement être représentées dans une enveloppe SOAP).

Plus standardisé - les opérations HTTP sont bien comprises et fonctionnent de manière cohérente. Certaines implémentations SOAP peuvent devenir capricieuses.

Plus lisible et testable par l'homme (plus difficile à tester SOAP avec juste un navigateur).

Vous n'avez pas besoin d'utiliser XML (enfin, vous n'êtes pas obligé de le faire pour SOAP non plus, mais cela n'a guère de sens puisque vous faites déjà l'analyse de l'enveloppe).

Les bibliothèques ont rendu SOAP (en quelque sorte) facile. Mais vous évitez beaucoup de redondance en dessous, comme je l'ai noté. oui en théorie, SOAP peut passer par d'autres transports afin d'éviter de chevaucher une couche en faisant des choses similaires, mais en réalité à peu près tout le travail SOAP que vous ferez est sur HTTP.


1
Je voudrais ajouter que la communication SOAP inter-plate-forme peut également être un PITA (cela ne faisait-il pas partie du point de SOAP?!?).
Justin Bozonier

7
Fonctionne également très bien avec l'infrastructure HTTP - par exemple, les GET sont mis en cache de manière agressive avec l'utilisation de la dernière modification et des étiquettes
James Strachan

Travailler parfaitement avec les navigateurs Web pour fournir un client universel à vos services aide également :)
James Strachan

2
Je dirais que SOAP est bien standardisé. Si vous voulez dire que les implémentations sont immatures, il peut être judicieux de clarifier cela. J'apprécierais certaines preuves pour ce point de vue si vous suggérez cela. Je me demande également si REST est plus lisible par l'homme, cela dépend entièrement de la façon dont vous choisissez de formater votre contenu. Et rappelez-vous également que XML est conçu pour être lisible par l'homme, bien qu'il soit verbeux comme nous le savons tous.
Howard mai

6
HTTP est tout aussi standardisé que SOAP et existe depuis plus longtemps, de sorte que les implémentations sont vraiment stables dans tous les domaines et vraiment interopérables. SOAP sera également intrinsèquement moins lisible même avec un contenu identique, en raison de l'enveloppe dans laquelle le contenu est enveloppé. En pratique, au cours des dernières années, j'ai trouvé que JSON sur HTTP était la meilleure combinaison, juste assez lisible tout en étant encore plus compact.
Kendall Helmstetter Gelner

36

Les services RESTful sont beaucoup plus simples à utiliser que les services (réguliers) basés sur SOAP . La raison en est que REST est basé sur des requêtes HTTP normales, ce qui permet de déduire l'intention du type de requête en cours (GET = retrive, POST = write, DELETE = remove, etc ...) et est complètement sans état. D'un autre côté, vous pourriez affirmer qu'il est moins flexible car il supprime le concept d'une enveloppe de message contenant un contexte de demande.

D'après mon expérience, SOAP a été préféré pour les services au sein de l'entreprise et REST a été préféré pour les services exposés en tant qu'API publiques.

Avec des outils comme WCF dans le framework .NET, il est très simple d'implémenter un service en tant que REST ou SOAP.

Quelques lectures pertinentes:


9
Je crois comprendre que les fichiers WSDL peuvent être utilisés pour générer des classes afin d'exposer les méthodes du service Web. Cela rend-il la consommation des services aussi simple que l'appel d'une fonction? Pouvez-vous expliquer votre point de vue un peu plus s'il vous plaît.
Howard le

1
Howard May: En supposant que vous appelez des fonctions en utilisant uniquement des types de données primitifs, c'est certainement vrai. Mais dans ce cas, vous ne pouvez pas dire exactement que SOAP est plus facile que de se reposer. Si vous avez des types de données complexes, le traitement WSDL peut fonctionner correctement entre deux machines avec les mêmes piles WS. Mais vous aurez inévitablement des problèmes dès que vous mélangez des piles. Cela cesse d'être si facile une fois que vous devez creuser manuellement dans WSDL pour déboguer les incompatibilités.
Joseph Holsten

1
En 2014, presque toutes les plates-formes, même les plus anciennes, prennent en charge WSDL. Les classes proxy rendent l'utilisation de l'API extrêmement simple. Nous implémentons un service push et j'envisage REST, mais j'ai vraiment du mal à voir les avantages.
JohnOpincar

13

Je suppose que lorsque vous dites "services Web", vous voulez dire SOAP et l'ensemble de normes WS- *. (Sinon, je pourrais affirmer que les services REST sont des "services Web".)

L'argument canonique est que les services REST correspondent plus étroitement à la conception du Web, c'est-à-dire à la conception de HTTP et de l'infrastructure associée. Ainsi, l'utilisation d'un service REST sera plus compatible avec les outils et techniques Web existants.

Bien sûr, une fois que vous explorez les détails, vous découvrez que les deux approches ont des avantages dans différents scénarios. Ce sont ces détails qui vous intéressent?


10

La surcharge n'est pas aussi importante qu'une bonne architecture.

REST n'est pas un protocole, c'est une architecture qui encourage une bonne conception évolutive. Il est souvent choisi car trop de liberté dans RPC peut facilement conduire à une mauvaise conception.

L'autre raison est le coût prévisible des protocoles RESTful sur HTTP, car il peut tirer parti des technologies existantes (principalement des proxies). Le coût initial du RPC est assez faible mais il a tendance à augmenter considérablement avec l'intensification de la charge.


7

REST est indépendant de la mise en œuvre et beaucoup plus transparent, ce qui le rend idéal pour les API publiques, en particulier pour les grands sites Web comme Flickr, Amazon ou Digg qui utilisent leurs API comme outils de marketing et veulent vraiment que les gens consomment leurs données. Ils ne veulent pas être des milliers de développeurs novices qui essaient de déboguer la bibliothèque SOAP boguée du langage de script de leur choix.

Par rapport à SOAP et WSDL, qui sont meilleurs pour les applications internes, où vous avez des bibliothèques de dépôt et des personnes connues des deux extrémités. (Et vous n'avez peut-être pas à vous soucier de choses comme l'équilibrage de charge à l'échelle Internet, la mise en cache HTTP, etc.) Ensuite, vous obtenez des API qui sont auto-documentées, préservent les types, etc. sans travail.


Une bonne réponse, mais je ne suis pas d'accord avec le fait que SOAP signifie que vous ne pouvez pas avoir d'équilibrage de charge à l'échelle Internet.
HDave

7

Je dois lire la plus excellente dissertation de Roy Fielding sur le sujet. Il fait un excellent cas et a été sans aucun doute FAÇON avance sur son temps quand il l' a écrite (2000).



5

REST permet à vos opérations non mutantes (qui utilisent généralement le verbe GET) d'être mises en cache . Autrement dit, mis en cache par le client et / ou mis en cache par des mandataires. Cela peut être une énorme victoire!


8
C'est simplement «utiliser HTTP correctement» et non REST.
aehlke le

3

REST est essentiellement un moyen d'implémenter des services Web. C'est juste un moyen d'utiliser correctement HTTP pour interroger les services Web que vous essayez d'accéder.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer


1
REST n'a rien à voir avec HTTP et est entièrement indépendant du protocole. Il est cependant bien adapté à certains types de services Web centrés sur les ressources.
aehlke le

0

C'est super simple et mince. Vous pouvez le faire avec le navigateur via le verbe http: GET. Je n'ai pas trouvé de navigateur capable de faire manuellement une requête POST http générique facilement


1
Checkout Fiddler. Ce n'est pas un navigateur mais c'est un excellent moyen de créer des HTTP POST sans code. fiddler2.com/fiddler2
Eric Schoonover

Je le fais normalement en modifiant la demande existante avec Charles. J'ai aussi Fiddler.
Ray Lu

0

Voici un point de données: Amazon propose ses API aux formats REST et SOAP et 85% de l'utilisation est REST.

REST est plus facile à implémenter, plus facile à comprendre et plus performant.


7
Avez-vous des références pour votre déclaration de «performance supérieure»?
James McMahon

3
Où avez-vous eu 85% d'utilisation? C'est très bon à savoir (si je peux voir la preuve)
schmoopy

3
La lecture manuelle d'une spécification d'API, l'impression de pages, etc. est plus facile à implémenter que "Clic droit, Ajouter une référence de service"? (VS2010)
BlueChippy

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.