SOAP vs REST - Understanding the Underlying Differences

SOAP vs REST - Understanding the Underlying Differences

2014, Oct 05    

I’ve never used Simple Object Access Protocol (SOAP), because, since I’ve been a developer, I’ve always been involved in projects using Representative State Transfer (REST) services. Turns out, this wasn’t as simple of a question as I’d hoped.  Also, it seems that it’s not an old protocol that nobody should use.  It actually has plenty of good uses and a bunch of solid tools too.


  • Supports multiple data formats, but usually XML-based messaging is used for strict schema design.
  • The protocol has a bit of overhead for hand shaking (even if the Message Transmission Optimization Mechanism reduces the message sizes significantly.)
  • Can be implemented over any transport layer (HTTP, SMTP, JMS, etc)
  • Requires Web Services Description Language (WSDL), which can be used in proxies/caches.  This defines interfaces of services and must be shared with whomever might be accessing your application
  • Reliable - Retries are handled for you as part of the framework overhead
  • All parts of the communication can be encrypted (even parameters)
  • Strongly typed
  • Extra security can be built in (WS-Security)
  • Atomic operations can be built in.  More than just transactions.
  • Methodology: Exposes operations that can be done
  • The core APIs on the JVM is JAX-WS
  • Popular Java implementations include AXIS, CXF, and Spring-WS


  • Supports multiple data formats - The most popular is JSON, but it also supports many other known types.  With JSON, it tends to allow for human readable results.
  • Considered to be a more lightweight solution - especially on the front end.  Easy to build, no toolkits required. Though, it is still easier to access with libraries.
  • Implemented directly on top of HTTP
  • Emphasis on stateless communication - with the exception of POST/PATCH HTTP operations.  All others are idempotent (can be repeated without repercussions - for example, if you are cacheing responses).
  • Proxies/Caches need a custom solution
  • Not strongly typed.
  • Supports transactions, but not atomic operations
  • Not reliable - retries have to be handled by application
  • Methodology: Exposes resources, which represent data, and actions that can be done upon them
  • The core APIs on the JVM is JAX-RS
  • Popular Java implementations include CXF, Jersey, RESTEasy, and Spring-MVC.


So, looking at these, your architectural decisions should be based on the strengths of each protocol.  Actually, you don’t even need to use just one, you could use both.  In summary:

REST = good for Web services, limited bandwidth/resources, and combining content from many different sources in a web browser

SOAP = good for Enterprise services with an abundance of processing power - includes high reliability, transactions, security built in, asynchronous processing, and contract first development.  Also, the strict schema makes is very good for passing around a lot of data.

99% of the time, I’m going to suggest REST as a protocol, especially since most of my work is web facing products only. However,  now that I know a bit more about SOAP and how servers can use them for communications, I know what to do during the other 1% of the time.

Further reading material:

Makeup of SOAP - a comparison

Video Introduction to SOAP