Enterprise Integration Zone is brought to you in partnership with:

Behind DotNetBlocks.com is a software engineer with over 10 years of experience in Microsoft technologies and is currently obtaining a Masters in IT. His primary focus is typically on software architecture, web applications, and interactions amongst various systems. Todd is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

When to use SOAP over REST

12.26.2012
| 10970 views |
  • submit to reddit
So, how does REST based services differ from SOAP based services, and when should you use SOAP? Representational State Transfer (REST) implements the standard HTTP/HTTPS as an interface allowing clients to obtain access to resources based on requested URIs. An example of a URI may look like this http://mydomain.com/service/method?parameter=var1&parameter=var2. It is important to note that REST based services are stateless because http/https is natively stateless.

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:

Published at DZone with permission of Todd Merritt, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

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é

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.