SOAP vs REST in the service layer for mobile applications
With the surge in native mobile applications and the advent of players like Android, IPhone, Palm and other big players into this market, providing frameworks to develop applications native to the device, it is important for developers to understand performance implications for every operation that the application is going to perform.
WHY THE PROMINENCE?
The service layer has always been a most important factor for any enterprise as that is where they have put all their money in. During the last ten years, organizations have made significant investments in SOAP-based infrastructure such as Enterprise Service Buses (ESBs) and Business Process Management (BPM) software based on WS-BPEL. The SOAP binding will allow organizations to leverage those investments in building interoperable content repositories.
Within the enterprise and in B2B scenarios, SOAP is still very attractive. This is not to say that REST is not enterprise ready. In fact, there are known successful RESTful implementations in mission critical applications such as banking. However, enterprise applications can have specific requirements in the areas of security, reliable messaging, business process execution, and transactions for which SOAP provides solutions.
SO, WHY THE CONFUSION?
With the advancement in hardware for the devices under smart phone category and the increasing usage of mobile internet, consuming web services is imminent for a native application. Now the question arises as to which type of web services to implement and consume for a mobile application.
Although the debate is long standing and very trivial to what the application does and the scope of the users using the application, this article focuses on which is better, SOAP or ReST, in case of operations that are very much abode to mobile.
GPS, photos, videos or other media transfer, location based data exchange are some of the operation that an application developer would like to go into his mobile client or it might be the plain old stock quotes that he might want to add to his application as a ticker.
I have laid down the preferred ways of implementing and consuming the service in a way that I have always wanted and never have got, the domain/operation specific way. Before that I would want to tell you an easy pointer to tell the difference – You use SOAP to wash and you REST when you are tired!
EASE OF IMPLEMENTATION AND MAINTANENCE
In case of implementation, SOAP overtakes REST as there are established development kits in case of SOAP. But REST developers would argue that it’s got interface flexibility.
Verdict: SOAP
HEAVYNESS/LIGHTNESS
ReST is definitely lightweight as it is meant for lightweight data transfer over a most commonly known interface, - the URI. And there are many extension to it as one can easily implement and consume ReST/JSON service which matters a lot for mobile applications.
Verdict: ReST
BANDWIDTH USAGE
This is a very interesting and important parameter as in a mobile application there can be many more network calls which in turn calls for moderate bandwidth usage. SOAP requires an XML wrapper around every request and response. Once namespaces and typing are declared, a four- or five-digit stock quote in a SOAP response could require more than 10 times as many bytes as would the same response in REST. Like SOAP, REST still needs a corresponding document that outlines input parameters and output data.
The good part is that REST is flexible enough that developers could write WSDL files for their services if such a formal declaration was necessary. Otherwise it could be a human readable declaration.
Verdict: ReST
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.
Verdict: ReST
SECURITY
This is much of a debatable and dicey parameter as it depends on what you transmit. Although the SOAP camp insists that sending remote procedure calls through standard HTTP ports is a good way to ensure Web services support across organizational boundaries, REST followers argue that the practice is a major design flaw that compromises network safety. REST calls also go over HTTP or HTTPS, but with REST the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request. For example, a GET request can always be considered safe because it can't, by definition, modify any data. It can only query data.
A typical SOAP request, on the other hand, will use POST to communicate with a given service. And without looking into the SOAP envelope—a task that is both resource-consuming and not built into most firewalls—there's no way to know whether that request simply wants to query data or delete entire tables from the database.
As for authentication and authorization, SOAP places the burden in the hands of the application developer. The REST methodology instead takes into account the fact that Web servers already have support for these tasks.
Verdict: SOAP/ReST
Who uses ReST?
All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.
Who uses SOAP?
Google seems to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.
CONCLUSION
We sure must take into account the fact that ReST is not for everything. There are situations wherein ReST proves the best, but one mustn’t forget the scope of SOAP is too large and there is much backing for SOAP and many large enterprises thrive on SOAP in their service layer.
Comments