20 Jan, 2009
HTTP vs REST vs SOAP
Posted by Bhavin Turakhia
I have been an active proponent of SOAP since its inception. SOAP revolutionzed RPC and loose coupling to a great extent. However off late I have been giving APIs and interfaces considerable thought and am leaning a lot more towards simple HTTP based APIs with an XML or JSON response format as opposed to SOAP. In this post I pen down some random thoughts on the merits and demerits of each.
Introduction
Let me first clarify the terminology -
- SOAP refers to Simple Object Access Protocol
- HTTP based APIs refer to APIs that are exposed as one or more HTTP URIs and typical responses are in XML / JSON. Response schemas are custom per object
- REST on the other hand adds an element of using standrdized URIs, and also giving importance to the HTTP verb used (ie GET / POST / PUT etc)
Typing
SOAP provides relatively stronger typing since it has a fixed set of supported data types. It therefore guarantees that a return value will be available directly in the corresponding native type in a particular platform. Incase of HTTP based APIs the return value needs to be de-serialized from XML, and then type-casted. This may not represent much effort, especially for dynamic languages. Infact, even incase of copmlex objects, traversing an object is very similar to traversing an XML tree, so there is no definitive advantage in terms of ease of client-side coding.
Client-side effort
Making calls to an HTTP API is significantly easier than making calls to a SOAP API. The latter requires a client library, a stub and a learning curve. The former is native to all programming languages and simply involves constructing an HTTP request with appropriate parameters appended to it. Even psychologically the former seems like much less effort.
Testing and Troubleshooting
It is also easy to test and troubleshoot an HTTP API since one can construct a call with nothing more than a browser and check the response inside the browser window itself. No troubleshooting tools are required to generate a request / response cycle. In this lies the primary power of HTTP based APIs
Server-side effort
Most Programming languages make it extremely easy to expose a method using SOAP. The serialization and deserialization is handled by the SOAP Server library. To expose an object’s methods as an HTTP API can be relatively more challenging since it may require serialization of output to XML. Making the API Rest-y involves additional work to map URI paths to specific handlers and to import the meaning of the HTTP request in the scheme of things. Offcourse many frameworks exist to make this task easier. Nevertheless, as of today, it is still easier to expose a set of methods using SOAP than it is to expose them using regular HTTP.
Caching
Since HTTP based / Rest-ful APIs can be consumed using simple GET requests, intermediate proxy servers / reverse-proxies can cache their response very easily. On the other hand, SOAP requests use POST and require a complex XML request to be created which makes response-caching difficult
Conclusions
In the end I believe SOAP requires greater implementation effort and understanding on the client side while HTTP based or REST based APIs require greater implementation effort on the server side. API adoption can increase considerably if a HTTP based interface is provided. Infact an HTTP-based API with XML/JSON responses represents the best of both breeds and is easy to implement on the server as well as easy to consume from a client
Have been through a lot of articles comparing Restful API’s OR HTTP based API’s to SOAP – this clearly stand out, just tweeted this and bookmarked this
Nice informative blog…
@rizwan & @neha: Thanks
This your blog is very informative and interesting, would try to add some more information to it.
Actually, you might want to have a look at some very cool stuff I have been evaluating for a tech project (rather a vision) very recently.
1. Tibco General Interface + DWR
2. WSO2 Stack
3. Glassfish Suite (from Sun – I think it’s rather an overkill)
And, not to stop at the above formats, GI uses CDF aka Common Data Format. And then, Google uses its own proprietary but freely usable “Protocol Buffers”.
Honestly, “Sky” is the limit – it just doesn’t end – and isn’t as simple as it should have been.
Your analysis is more or less bang on except that we don’t develop web applications from scratch anymore. The framework that we use may make it a lot easier to support REST api on the server side. Ruby on Rails is one such example. Supporting XML/JSON formats in addition to HTML is a piece of cake in rails’ controllers.
One more thing: True REST style APIs make use of all HTTP methods such as GET, (for index/show/new/edit) POST for (create), PUT (for update), and DELETE (for destroy). This is what HTTP was designed for but somewhere in the middle, the browsers dropped support for requests other than GET and POST.
Nice article.
As part of “client side”, i couldn’t agree more that the HTTP based API has huge advantages.
Really hope that it will be used more and more in the near future, even if it is harder for implementation on server-side.
I am curious if it’s justified for API providers, implementing something like “mixed type API”, capable of using SOAP for all accessible with API features and using HTTP based API for only most frequently used on client side features of the API ?
This way, on client side will be possible to choose between simple solution with fast learning curve, or features rich and harder for development and realisation solution.
There seems to be large chunks of identical text between your article and this one…
http://www.taranfx.com/blog/rest-vs-soap-using-http-choosing-the-right-webservice-protocol
…I think you have been copied without being quoted as a reference.
I think Jim is correct … Bhavin, you just lifted out straight portions from Taranfx’s blog. Disappointing.
@Shakul: you seem to have gotten your facts wrong. it is the other way around. you ought to have checked the publishing dates on both articles before pointing fingers. or maybe atleast properly read Jim’s comments.
Hi Dude..
Still lacks in REST..Please ellabore.. REST with WCF and web services..
Bhavin, nice article.
Shared it with my entire team…
One can run any article link through
http://www.copyscape.com/
to find out who else is stealing your content ( or other way round who was the original source of information ! )
That was really informative! Thanks for sharing your views.
-Sunil.
Rosetta Stone Spanish (Latin America) Level 1 with Audio Companion. I have used this popular Spanish rosetta stone software to learn Spanish with mix results.Our “TopTenREVIEWS Bronze Award” went to Rosetta stone french, a recognized leader in the language learning industry. Note for Intel Macintosh Users: rosetta stone V3 application for Macintosh is a universal application that will run natively on Intel Macs.Learn French in your own time and have fun.
z
You simply cannot equate REST and SOAP. The latter is used for Web Services and the former should not be used for Web Services. It goes against the very definition of REST.
REST is a style of architecture, whereas SOAP is a set of protocols. In fact it makes more sense at least in theory to compare HTTP and SOAP.