Question

Il y a une controverse que je vois dans l'utilisation des API Web (services RESTful) pour accéder infrastracture à distance. Je vous serais reconnaissant, si vous pouvez le commenter. La recommandation venant de l'article "RESTful Web Services par rapport aux "Big" Web Services: Faire la bonne décision architecturale" [1] est d'utiliser des API Web plutôt pour une intégration ad hoc (à la » mashup) et le prototypage rapide. Les études empiriques réalisées dans [2] montre ces recommandations est suivie dans scenarious de réutiliser les informations existantes et de fonctionnalité. Cependant, l'infrastructure de réutilisation des API Web ne correspond pas bien dans la tâche d'intégration ad hoc. Mon impression est plutôt que l'infrastructure est généralement réutilisée dans des scénarios où les ressources que je n'ai pas bien échelle pour le problème que je veux résoudre un grand nombre de données, une bande passante élevée, haute concurrence. Néanmoins, Amazon offre un accès à distance à leur infrastructure (espace de stockage, un message queueuing) à la fois par:

  • Services Web SOAP classique (soi-disant grands services Web) et
  • lumière RESTful services Web (appelé API Web).

Bien qu'il n'y ait rien écrit si les clients (décrits dans les études de cas d'Amazon Web Services) utilisent Big services Web ou API Web, le fait que Amazon donne accès à leur infrastracture sous forme d'API Web comme une alternative doit être significative.

Savez-vous ce qui peut être leur motivation? Connaissez-vous des cas où les gens réutilisés infrastracture juste pour le prototypage rapide? Ou peut-être pour les tests? En d'autres termes, si je voudrais l'infrastructure réutilisation offerte par l'Amazone, le style API dois-je utiliser SOAP ou REST dans quelles situations par exemple?

EDIT: Dans ce cas comme une infrastructure que je voulais dire: l'espace de stockage, puissance de calcul, la bande passante Internet. Ainsi, je me demande si ces ressources sont réutilisés dans l'intégration ad hoc.


  1. Cesare Pautasso, Olaf Zimmermann, Frank Leymann, RESTful Web Services vs Web Services "Big". Prendre la décision droit d'architecture , pp 805-814, Jinpeng Huai, Robin Chen , Hsiao-Wuen l'honorable, Yunhao Liu, Wei-Ying Ma, Andrew Tomkins, Xiaodong Zhang (Ed.), Compte rendu de la 17ème large Conférence Web internationale mondiale , ACM Press, Beijing, Chine, Avril 2008 .

  2. Hartmann, Bjorn & Doorley, Scott & Klemmer, Scott R., Piratage, Brassage, Encollage: Comprendre Opportuniste design , IEEE Pervasive Computing , vol. 7, no. 3, 46-54 (2008).

Était-ce utile?

La solution

La clé pour comprendre la version à utiliser réside dans la compréhension d'une chose - si vous avez besoin d'effectuer des opérations complexes sur le Web avec des hiérarchies d'objets profondément ancrées, alors vous êtes effectivement forcé dans l'utilisation des services Web. REST est exceptionnellement capable quand il s'agit d'effectuer des opérations simples, mais les opérations complexes briser en dehors de son mandat.

J'aime généralement envisager des systèmes RESTful comme ceux que je peux tester simplement en invoquant une commande dans la barre de commande du navigateur. applications RESTful sont vraiment faciles à tester, et sont généralement très appropriés pour tester par moquerie.

Autres conseils

Je pense que quand les gens parlent de tirer parti des infrastructures existantes avec les services Web RESTful, ils veulent dire qu'ils peuvent utiliser des choses existantes conçues pour le web plutôt que d'avoir à utiliser un logiciel conçu spécialement pour les services Web. Par exemple, si j'ai un service Web en utilisant REST je peux profiter des choses comme proxy de mise en cache HTTP, où pour obtenir la fonctionnalité équivalente avec SOAP je besoin de quelque chose spécialisé.

REST est infiniment plus facile à utiliser que SOAP. FWIW, Google ne plus utiliser SOAP, il est tout REST.

Le seul avantage de SOAP est que vous obtenez des objets à utiliser dès la sortie de la boîte. Avec REST, soit vous avez besoin d'un cadre, comme JAX-RS, pour créer ces objets pour vous, ou les analyser manuellement.

Un autre grand avantage de REST, est que vous pouvez réellement voir les demandes dans vos journaux d'accès. La plupart des requêtes SOAP POST au même point final exact, il est donc une tonne plus difficile de déterminer ce que vous essayez de faire. D'autre part, REST généralement à des postes spécifiques points d'extrémité, de sorte que vous pouvez réellement les frapper de votre navigateur web w / o la nécessité d'une application de fantaisie.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top