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

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?

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.

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:

• Blog Amazon Web Services: REST vs SOAP
• Dare Obasanjo écrit souvent sur REST

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?

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.

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.

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).

Le blog de Steve Vinoski et ses derniers articles valent certainement la peine d'être parcourus. C'est un ancien gourou de CORBA, qui a probablement écrit le meilleur livre sur le sujet avec Michi Henning, "Advanced CORBA® Programming with C ++" . Cependant, il a depuis vu l'erreur de ses voies client / serveur, et jure maintenant par REST.

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!

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

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

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.