Why SOAP?
Here are a few reasons you may want to use SOAP.
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.
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 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.
Source: http://spf13.com/post/soap-vs-rest/