SOAP vs REST

Posted on June 17, 2011 by Shawn Mehan

I was in a discussion the other day with someone questioning REST over SOAP and why on earth one would use REST rather than SOAP. Following are some thoughts on the matter.So, firstly, the idea of remote execution is not new. RPC harkens back to at least 1976, described in a formal manner in RFC 707, where messages were initiated by a client to a different address space, usually on another network computer. There has been a steady evolution of remote execution function call specifications, and with the advent of the web, there, ofc, came a host of web service protocols, designed to work with web transports and systems. SOAP and REST are but two of these, albeit probably the most widespread by far.

SOAP

SOAP comes from the bowels of XML-RPC, which was done way back in 1998. SOAP once stood for Simple Object Access Protocol but this was dropped with v1.3 of the standard, being blessed on June 24, 2003. SOAP was born of Microsoft, based on WSDL and UDDI. WSDL and UDDI have faded, but SOAP has much of its DNA in these specs. SOAP is currently owned by the W3C.

SOAP characteristics:

• Exposes operations that represent logic
• provides a loose coupling for integrating diverse systems
• designed to be extensible with the raft of WS-* specifications
• Designed for distributed computing
• Has a standard error messaging and error types
• Aligns with EA requirements in that it supports various transports, e.g. HTTP, SMPT, UDP, JMS, etc.
• supports enterprise security with WS-Security
• supports language neutrality (you can use it with JAVA, Python, Ruby, Lisp, Perl, PHP, C, C#, etc.)
• is ACID when using WS-AT
• With WS-RM supports reliable messaging
• Has strong typing, so supports strong governance
• broadly supported in the industry

REST

REST was developed in parallel with HTTP/1.1. The largest implementation of a REST system is something called with WWW. REST works on a server-client conceptual basis, again, with clients initiating requests to servers, which process and return responses. This request / response paradigm is built upon the transfer of resource representations. A RESTFUL approach is not limited to HTTP, by the way. But, an example of HTTP yields the REST verbs (read methods from an OOP paradigm), URIs, Internet media types, request and response codes, etc. Here is a maintained list of REST examples.

Importantly, there are constraints on a design to maintain its RESTFUL nature. These are meant to be helpful, constraining forces:

1. Client-server
2. Stateless
3. Cacheable
4. Layered System
5. Uniform interface – decouples architecture to allow client and server to evolve independently
6. Code on demand (optional) – a server can pass logic to a client that may be executed, e.g. javascript or (shudder) applets.

Comparison

• REST exposes resources that represent data, while SOAP exposes operations that represent logic
• REST uses VERBS (Methods: GET/POST/DELETE) while SOAP uses the one verbPOST
• REST emphasises simple p2p communication over HTTP, while SOAP emphasised loosely coupled distributed messaging
• REST supports multiple data formats, while SOAP encodes everything in XML with data attachments
• REST emphasises stateless communication while SOAP supports stateless and stateful operations
• SOAP is better at asynchronous messaging, pub/sub and has strong typing (in the WSDL)

Strengths

REST has benefits because:

• REST can be consumed by any client, even a web browser using Ajax and .js
• REST is lightweight. Doesn’t require XML parsing, consumes less BW, doesn’t require a SOAP header for each message
• REST is very widespread and highly adopted by many web resources
• REST can be made very safe, since one can filter on anything that is not a GET verb.
• Great for web services, exposing data over the internet.
• Great for low BW and CPU requirements.
• Great for combining data from multiple sources in a browser.

SOAP has benefits also:

• SOAP will allow for custom exception codes, will allow for client side artefacts from a WSDL, has strong support in many IDEs
• SOAP is much easier to use for stateful, asynchronous designs
• SOAP is considered more secure by many because parameters are encoded in the message, not the URI. SOAP has support for contracts, acquiring tokens, etc. Note that REST doesn’t require params in the URI, but it often happens. Many would argue that this is breaking REST.
• SOAP has reliability as part of its contract, e.g. WS-RM
• SOAP can be governed more easily, it can be discovered more easily
• Great for enterprise applications requiring contracts and reliability measures.
• Great for asynch processing

Many from the EA camp would argue that SOAP is more reliable, safe, secure, but if that is the case, how is the WWW working? Again, remember that the largest REST system in existence is the web. And that’s pretty impressive. Most of the modern web enterprises are exposing their data and services in REST and SOAP, but more and more in REST.

Tweet