Who does not know and dread the recurring discussion of a topic long thought dead? The most egregious one lately was a discussion about the applicability of RFC 2119 to a particular standard I was working on (to protect the innocent I will not disclose the name of the SDO) – the last time I had a discussion about the meaning of “SHOULD” was about 11 years ago… sigh!
But this is not the reason for my current urge to vent – a bug long thought dead is reappearing once more: the old discussion about REST vs. SOAP. It is really annoying for two reasons. Firstly, it is settled – both have their place, and pitting them against each other is pointless. But secondly, posing the question of “Is SOAP or REST better?” is – to paraphrase Mona Lisa Vito – a bu****it question.
Representational State Transfer (REST) is an architectural style, i.e. a general approach on how to design distributed computing architecture. While it was initially described by Roy Fielding using HTTP, and also uses constraints familiar from the web, it is not tied to a particular technology.
The Simple Object Access Protocol (SOAP) is – in contrast – a specific technology; more precisely an XML based protocol designed to transport data across a variety of different underlying transports. In real-world deployments it often uses HTTP (actually almost exclusively its POST method) as underlying transport for the SOAP Infoset. The architectural style used by many (if not most) SOAP designs is best captured by describing it as remote procedure call (RPC) oriented .
So a correct (in the sense of “apples to apples”) comparison would align itself along the lines of comparing HTTP web service using an RESTful architectural style with SOAP web services using an RPC-based architectural style. A simple, incomplete table might look like this:
|Commonly used protocol
|SOAP over HTTP/POST
|Any Internet Media TYpe
|Number of methods/verbs
|four (PUT, GET, POST, DELETE)
That’s it – rant over.
 Note that while SOAP operates typically in two different modes (rpc/encoded and doc/literal), these have nothing to do with the architectural style of the distributed design.