REST versus SOAP for the Public Cloud
There has been a lot of debate around what is better; SOAP based Web Services or RESTful services. This debate is sometimes surprisingly heated with expressions like WS-Deathstar and RESTafarian tossed around all over the place. This is yet another interjection into that debate that specifically focuses on the public cloud.
To make the context clear, in this post I want to discuss services that are publically available and hosted in the cloud – SaaS. The services I have in mind are services that are meant to get a wide adoption across multiple countries, technologies and devices.
According to the NIST-definition of cloud computing the ability to pool resources to serve multiple client organizations (a.k.a. tenants) is an essential characteristic of cloud computing. A multi-tenant service is a service that serves many. The opposite of multi-tenancy is having different services for different clients.
Supporting multiple clients
Supporting multiple clients with one service can be difficult as it involves designing for reuse. Neither Web Services nor REST services can guarantee that our services will be reusable or posess any of the other beneficial properties that we commonly associate with SOA. Despite that fact I still think that REST has an advantage over Web Services in this case – and the reason is purely about technology.
The dominant (or only) way to implement REST services today is to utilize HTTP. HTTP is supported by a huge amount of server and client technologies that are found in various different assets ranging from the biggest servers (even mainframes) to PCs and cellphones. This is a really good match for multi-tenancy as it is to be expected that different client organizations consume services using different technologies and different assets. HTTP was recently described as a credit card that is always accepted everywhere.
As for Web Services there is extensive support for that too, but way less than the support for HTTP.
Servicing multiple clients
When you are servicing multiple clients you need to worry about performance. A service with better performance will be able to handle more requests with the same amount of resources. It will help you provide a good enough service to your customers in a more cost-effective way. In a lot of publically available services, information is read more often that it is written – this is (hopefully) true for tweets, facebook status updates and blog posts. Again, the difference between Web Services and REST is purely about technology.
The semantics of HTTP allows us to define in a standardized way how data should or could be cached. Due to this reason a horde of web enabled products have built in support for HTTP caching. Better yet, this caching functionality can be utilized in multiple layers. It means that not only the web server that hosts your cloud solution will be able to cache your data. Caching can be used in web servers that the request will pass on its way to your client, or even in the client software. When data is cached, some of the read requests to your service will never even have to reach your server. It will make the client applications perform better, and enable your service to take care of more clients.
As for Web Services there is no way to define caching in a standardized way.
Another way to investigate this question is to take a look at the real usage out there on the web. Statistics from the Programmable Web shows that REST has gone from a 60 % to a 74 % dominance on publicly available APIs. SOAP based Web Services on the other hand has plummeted from 25 % to 15 % during the same period. Back in 2003 (I haven’t been able to find anything newer than that) Amazon found that 85 % of customers preferred their RESTful API (they offer both REST and SOAP).
For services tageted for the public cloud, REST is a better option than SOAP based Web Services.
REST versus SOAP revisited
When people discuss REST in contrast to SOAP based Web Services they generally think of it as a dichotomy, when in reality we’re dealing with a whole range of options that is more akin to a continuum. Web Services with a lot of WS-* have a different level of complexity compared to Web Services with a little WS-*. Web Services without WS-* is even simpler than that. Of course the functionality that they can offer differ too. Using WS-* standards like WS-Addressing and WS-Security can offer detailed addressing features and a level of security that the simple Web Service cannot offer.
REST also comes in different flavors. Some of the flavors below may not be considered to be RESTful by all REST proponents, but when we discuss REST versus SOAP based Web Services they all tend to end up in the RESTful corner.
The POX – Plain Old XML over HTTP – approach use HTTP as a transport protocol and transfer data using XML. It is similar to SOAP based Web Services, but doesn’t have a SOAP envelope or a WSDL. It is a way of doing RPC with data transferred in the body of the request.
The URI tunneling approach use HTTP as a transport protocol and is further based on URI templates. It uses the URI to transfer data, i.e. the data is transported inside the query string.
The CRUD – Create Read Update Delete – approach uses HTTP as an application protocol. Resources are identified with unique URIs and HTTP verbs (POST, GET, PUT and DELETE) are used to manipulate these resources. Data is transferred in the body and can be encoded using XML, JSON or other formats.
The HATEOAS – Hypermedia As The Engine Of Application State – approach uses HTTP as an application protocol and identify resources using unique URIs, just like CRUD. Furthermore it uses hypermedia, essentially links and forms, to guide the consumer through a number of interactions with the service. Popular standardized media types that allow for the use of hypermedia are ATOM and XHTML.
The maturity of publically available REST APIs
It seems to me that far from all those public RESTful APIs on the web qualify as hypermedia-enabled services. Below follows a few randomly picked examples that reinforces that thought:
- Twitter: This search result (XML+Atom) offer some links like the next page of the search result. However, they do not offer links like
- reply to
- Facebook: This search result (JSON) offers no hypermedia.
- Linkedin: The Connections API call (XML) offers no hypermedia.
- Amazon Elastic Compute Cloud: The Start Instances API call (XML) offers no hypermedia.