SOAP vs REST
Both methods are used by many of the large players. It's a matter of preference. My preference is REST because it's simpler to use and understand.
Roy Fielding was a member of the team that wrote the specification for HTTP and co-founder of Apache HTTP server project. He introduced the word REST and the concept in his doctoral thesis in 2000. REST disruptively took over as an architectural style for web services implementation.
- SOAP stands for Simple Object Access Protocol. REST stands for Representational State Transfer.
- SOAP is a XML based messaging protocol and REST is not a protocol but an architectural style.
- SOAP has a standard specification but there is none for REST.
- Whole of the web works based on REST style architecture. Consider a shared resource repository and consumers access the resources.
- Even SOAP based web services can be implemented in RESTful style. REST is a concept that does not tie with any protocols.
- SOAP is distributed computing style and REST is web style (web is also a distributed computing model).
- REST messages should be self-contained and should help consumer in controlling the interaction between provider and consumer(example, links in message to decide the next course of action). But SOAP doesn't has any such requirements.
- REST does not enforces message format as XML or JSON or etc. But SOAP is XML based message protocol.
- REST follows stateless model. SOAP has specifications for stateful implementation as well.
- SOAP is strongly typed, has strict specification for every part of implementation. But REST gives the concept and less restrictive about the implementation.
- Therefore REST based implementation is simple compared to SOAP and consumer understanding.
- SOAP uses interfaces and named operations to expose business logic. REST uses (generally) URI and methods like (GET, PUT, POST, DELETE) to expose resources.
- SOAP has a set of standard specifications. WS-Security is the specification for security in the implementation. It is a detailed standard providing rules for security in application implementation. Like this we have separate specifications for messaging, transactions, etc. Unlike SOAP, REST does not has dedicated concepts for each of these. REST predominantly relies on HTTPS.
- Above all both SOAP and REST depends on design and implementation of the application.
Why REST?
Here are a few reasons why REST is almost always the right answer.
Since REST uses standard HTTP it is much simpler in just about ever way. Creating clients, developing APIs, the documentation is much easier to understand and there aren’t very many things that REST doesn’t do easier/better than SOAP.
REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.
REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
It’s a bad argument (by authority), but it’s worth mentioning that Yahoo uses REST for all their services including Flickr and del.ici.ous. Amazon and Ebay provide both though Amazon’s internal usage is nearly all REST source. Google used to provide only SOAP for all their services, but in 2006 they deprecated in favor of REST source. It’s interesting how there has been an internal battle between rest vs soap at amazon. For the most part REST dominates their architecture for web services.
Why SOAP?
Here are a few reasons you may want to use SOAP.
WS-Security
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services have no need for, in fact they are really only needed in a few “enterprise” scenarios.
WS-AtomicTransaction
Need ACID Transactions over a service, you’re going to need SOAP. While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. Fortunately ACID transactions almost never make sense over the internet. REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps generally don’t need this level of transactional reliability, enterprise apps sometimes do.
WS-ReliableMessaging
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
Summary
In Summary, SOAP is clearly useful, and important. For instance, if I was writing an iPhone application to interface with my bank I would definitely need to use SOAP. All three features above are required for banking transactions. For example, if I was transferring money from one account to the other, I would need to be certain that it completed. Retrying it could be catastrophic if it succeed the first time, but the response failed.
