When to use SOAP over REST
One of the many benefits for implementing HTTP/HTTPS as an interface is can be found in caching. Caching can be done on a web service much like caching is done on requested web pages. Caching allows for reduced web server processing and increased response times because content is already processed and stored for immediate access. Typical actions performed by REST based services include generic CRUD (Create, Read, Update, and Delete) operations and operations that do not require state.
Simple Object Access Protocol (SOAP) on the other hand uses a generic interface in order to transport messages. Unlike REST, SOAP can use HTTP/HTTPS, SMTP, JMS, or any other standard transport protocols. Furthermore, SOAP utilizes XML in the following ways:
- Define a message
- Defines how a message is to be processed
- Defines the encoding of a message
- Lays out procedure calls and responses
As REST aligns more with a Resource View, SOAP aligns more with a Method View in that business logic is exposed as methods typically through SOAP web service because they can retain state. In addition, SOAP requests are not cached therefore every request will be processed by the server.
As stated before Soap does retain state and this gives it a special advantage over REST for services that need to preform transactions where multiple calls to a service are need in order to complete a task. Additionally, SOAP is more ideal for enterprise level services that implement standard exchange formats in the form of contracts due to the fact that REST does not currently support this.
A real world example of where SOAP is preferred over REST can be seen in the banking industry where money is transferred from one account to another. SOAP would allow a bank to perform a transaction on an account and if the transaction failed, SOAP would automatically retry the transaction ensuring that the request was completed. Unfortunately, with REST, failed service calls must be handled manually by the requesting application.
References:
- Francia, S. (2010). SOAP vs. REST. Retrieved 11 20, 2011, from spf13: http://spf13.com/post/soap-vs-rest
- Rozlog, M. (2010). REST and SOAP: When Should I Use Each (or Both)? Retrieved 11 20, 2011, from Infoq.com: http://www.infoq.com/articles/rest-soap-when-to-use-each
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Dean Schulze replied on Wed, 2012/12/26 - 11:23am
Good article. I would add a couple of points.
REST with JSON is lighter weight than SOAP which is why it is used so much on mobile devices. REST with JSON will be a better choice in many cases for resources that have to support mobile devices.
Another area where SOAP and REST differ is in security. SOAP has a standard security implementation in WS-Security whereas with REST you have to create your own security.
André Pankraz replied on Wed, 2012/12/26 - 4:00pm
Hi,
nice article. I don't see this Web-cacheable as such a big advantage for REST.
It would just be useful for REST read-only services (like often used in the mobile world and there it is especially nice because of scalability).
On the other hand Web-Proxy-Caches are often unreliable. Multiple Caching standards/versions and wrong implementations/configurations in uncontrollable Web Proxies are sufficient for HTML (even though Ajax-guys will sing a song about this) but not allways OK for REST services.
For SOAP you have multiple integration frameworks and ESBs that all (the good ones) support read-only sevice-caching in a much more controllable fashion.
Cheers,
André