Simple Object Access Protocol (SOAP) brings its own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each implements some business logic through different interfaces. Do you know, Why anyone chooses SOAP??
Though SOAP is commonly referred to as “web services” this is a misnomer. SOAP has very little if anything to do with the Web. REST provides true “Web services” based on URLs and HTTP. 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-Atomic Transaction: 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 a two-phase commit across distributed transnational resources, but SOAP can. Internet apps generally don’t need this level of transnational reliability, enterprise apps sometimes do.
WS-Reliable Messaging: 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.