Are RESTful Web services right way for re-using infrastructure?

Question

There is one controversy I see in using Web APIs (RESTful service) to access remote infrastracture. I would be grateful, if you could comment it. The recommendation coming from the article "RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision" [1] is to use Web APIs rather for ad hoc integration (a la' mashup) and rapid prototyping. Empirical studies made in [2] shows these recommendation is followed in scenarious of re-using the existing information and functionality. However, re-using infrastructure with Web APIs does not fit well into the task of ad hoc integration. My impression is rather that infrastructure is usually re-used in scenarios where the resources I have do not scale well for the problem that I want to solve: large number of data, high bandwidth, high concurrency. Nevertheless, Amazon provides remote access to their infrastructure (storage space, message queueuing) both through:

• classical SOAP Web services (so called Big Web services) and
• light RESTful Web services (so called Web APIs).

Although there is nothing written whether the clients (described in case studies of Amazon Web Services) employ Big Web services or Web APIs, the fact that Amazon provides access to their infrastracture in form of Web APIs as an alternative must be meaningful.

Do you know what can be their motivation? Do you know any cases where people re-used infrastracture just for rapid prototyping? Or maybe for testing? In other words, if I would like to re-use infrastructure offered by the Amazon, which API style should I use SOAP or REST in what example situations?

EDIT: In this case as an infrastructure I meant: storage space, computational power, internet bandwidth. Thus I wonder whether such resources are re-used in ad hoc integration.

---

1. Cesare Pautasso, Olaf Zimmermann, Frank Leymann, RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision, pp. 805-814, Jinpeng Huai, Robin Chen, Hsiao-Wuen Hon, Yunhao Liu, Wei-Ying Ma, Andrew Tomkins, Xiaodong Zhang (Ed.), Proceedings of the 17th International World Wide Web Conference, ACM Press, Beijing, China, April 2008.

2. Hartmann, Bjorn & Doorley, Scott & Klemmer, Scott R., Hacking, Mashing, Gluing: Understanding Opportunistic Design, IEEE Pervasive Computing , vol. 7, no. 3, 46-54 (2008).

Answer 1

The key to understanding which version to use lies in understanding one thing - if you need to perform complicated operations over the web with deeply embedded object hierarchies, then you are effectively forced into using web services. REST is exceptionally capable when it comes to performing simple operations, but complex operations break outside its remit.

I typically like to envisage RESTful systems as being ones which I can test just by invoking a command through the browser command bar. RESTful applications are really easy to test, and are generally very suitable for testing via mocking.

Answer 2

REST is infinitely easier to use than SOAP. FWIW, Google doesn't use SOAP anymore, it's all REST.

The only advantage to SOAP is that you get objects to use right out of the box. With REST, you either need a framework, like JAX-RS, to create these objects for you, or parse them manually.

Another huge advantage of REST, is you can actually see the requests in your access logs. Most SOAP requests POST to the exact same endpoint, so it's a ton harder to determine what you were trying to do. On the other hand, REST typically posts to specific endpoints, so you can actually hit them from your web-browser w/o the need of a fancy app.

Answer 3

I think when people talk about leveraging existing infrastructure with RESTful web services they mean they can use existing things designed for the web rather than having to use software specifically built for web services. For instance if I have a web service using REST I can take advantage of things like HTTP caching proxies, where to get the equivalent functionality with SOAP I would need something specialized.