Pourquoi voudrait-on utiliser REST au lieu de SOAP?
J'ai assisté à une démo intéressante sur REST aujourd'hui, cependant, je ne pouvais imaginer une seule raison (et aucune n'a été présentée) pour laquelle REST est de toute façon plus simple ou plus facile à utiliser et à implémenter que une pile de services basée sur SOAP.
Quelles sont certaines des raisons pour lesquelles quiconque dans le "monde réel" utilise REST au lieu des services SOAP?
Moins de temps système (pas d'enveloppe SOAP pour encapsuler chaque appel)
Moins de duplication (HTTP représente déjà des opérations telles que DELETE, PUT, GET, etc. qui doivent sinon être représentées dans une enveloppe SOAP.).
Plus normalisé - Les opérations HTTP sont bien comprises et fonctionnent de manière cohérente. Certaines implémentations SOAP peuvent être difficiles.
Plus lisible et testable par l'homme (plus difficile à tester SOAP avec juste un navigateur).
Pas besoin d’utiliser XML (eh bien, vous n’êtes pas obligé de le faire pour SOAP non plus, mais cela n’a guère de sens puisque vous êtes déjà en train d’analyser l’enveloppe).
Les bibliothèques ont rendu SOAP (en quelque sorte) facile. Mais vous souscrivez beaucoup de redondance, comme je l’ai noté. oui, en théorie, SOAP peut passer par-dessus d'autres transports afin d'éviter de chevaucher une couche similaire, mais en réalité, presque tout le travail que vous ferez SOAP se fera sur HTTP.
RESTful Les services sont beaucoup plus simples à consommer que [~ # ~] soap [~ # ~] services (réguliers). La raison en est que REST est basé sur des requêtes HTTP normales, ce qui permet de déduire une intention du type de requête en cours (GET = retrive, POST = write, DELETE = remove, etc ...) et est totalement sans état. Vous pouvez par contre arguer que cette solution est moins flexible car elle supprime le concept d’enveloppe de message contenant le contexte de la demande.
D'après mon expérience, SOAP a été préféré pour les services 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:
Je suppose que lorsque vous parlez de "services Web", vous voulez dire SOAP et l'ensemble de normes WS- *. (Sinon, je pourrais soutenir que REST services are "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 avez exploré les détails, vous découvrez que les deux approches ont des points forts dans différents scénarios. Est-ce que ce sont ces détails qui vous intéressent?
Les frais généraux ne sont pas aussi importants qu'une bonne architecture.
REST n'est pas un protocole, c'est une architecture qui encourage une bonne conception évolutive. C'est souvent choisi parce que 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 exploiter les technologies existantes (principalement les serveurs proxy). Le coût initial du RPC est assez faible, mais il a tendance à augmenter de manière significative avec l'intensification de la charge.
Je dois lire l'excellent travail de Roy Fielding thèse sur le sujet. Il fait un excellent cas et était définitivement [~ # ~] [~ # ~] en avance sur son temps quand il l'a écrit (2000).
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 tels que Flickr, Amazon ou Digg qui utilisent leurs API comme outils de marketing et souhaitent vraiment que les utilisateurs consomment leurs données. Ils ne le font pas veulent avoir à la main des milliers de développeurs novices qui essaient de déboguer la bibliothèque boguée de leur langage de script de choix SOAP.
Versus SOAP et WSDL, qui sont meilleurs pour les applications internes, où vous avez des bibliothèques externes et des gens clairs connus des deux côtés. (Et vous n’aurez peut-être pas à vous soucier d’Internet Équilibrage de charge, mise en cache HTTP, etc.). Vous obtenez ensuite des API auto-documentées, des types préservés, etc. sans travail.
blog de Steve Vinoski et ses derniers articles valent vraiment le détour. Il est un ancien gourou de CORBA, qui a probablement écrit le meilleur livre sur le sujet avec Michi Henning, "Programmation CORBA® avancée avec C++" . Cependant, il a depuis vu l'erreur de ses méthodes client/serveur et ne jure que par REST.
REST permet à vos opérations non mutantes (qui utilisent généralement le verbe GET) d’être mises en cache. C'est-à-dire mis en cache par le client et/ou mis en cache par les mandataires. Cela peut être une victoire énorme!
REST est fondamentalement un moyen d'implémenter des services Web. C’est simplement une façon d’utiliser HTTP correctement pour interroger les services Web que vous essayez de toucher.
http://www.xfront.com/REST-Web-Services.htmlhttp://en.wikipedia.org/wiki/Representational_State_Transfer
Voici un point de données: Amazon propose ses API dans les deux formats REST et SOAP et 85% de l'utilisation est REST).
REST est plus facile à mettre en œuvre, à comprendre et à améliorer les performances.
C'est super simple et mince. Vous pouvez le faire avec un navigateur via http verbe: GET. Je n'ai pas trouvé de navigateur capable de faire une requête http POST générique manuellement