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 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.
Exposes operations that represent logic
provides a loose coupling for integrating diverse systems
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:
Uniform interface – decouples architecture to allow client and server to evolve independently
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)
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.