REST vs..?
Monday, 7 November 2005
More and more people are getting turned on to the advantages of using REST as a higher-level abstraction for networked applications, often comparing it favourably to SOAP and Web services.
However, as many have pointed out, this is a bad comparison to make; REST is an architectural style, while SOAP is a protocol. So, what should be compared?
When this question comes up, I’ve found it helpful to draw a table with different architectural styles in the columns, and protocols that implement them in the rows, filling in the cells with examples of each combination;
| SOA | RPC | REST | |
| SOAP | (native) | style=”rpc” | WS-Transfer, |
| WS-RF | |||
| HTTP | tunnelling | ||
| (e.g., SOAP) | POST-only HTTP, | ||
| XML-RPC | (native) |
There are, of course, many more protocols and architectural styles to choose from, but a few observations follow from this table already.
First of all, it’s clear that, with a bit of work, you can get any of the listed architectural styles with both SOAP and HTTP. SOAP can do this because its native architectural style, SOA, is a very low-level one (often summed up as “messaging is good”), so it’s possible to build up other architectural styles just by adding to it. Conversely, HTTP is a higher-level abstraction, formed around stateful resources, rather than messages. That said, it’s possible to get the other architectural styles with it by willingfully constraining its use.
Because of this, it’s easy to mischaracterise what architectural style is in use; while what protocol you’re using is obvious, architectural style is a more ephemeral thing. In particular, lots of “Web 2.0” applications say they expose “RESTful” interfaces, when in fact they’re just doing POST-only HTTP, thinking they automatically get the benefits of REST just because they use HTTP.
Apples to Apples
With this in mind, it’s more reasonable to compare protocols that implement a particular architectural style (I’ll leave the comparison of architectural styles to other blog entries).
When doing so, notice that REST is native in HTTP, and SOAP is native for SOA. Intuitively, I’d rather use HTTP if my chosen architectural style were REST, especially considering how widely deployed and provably interoperable it is. I can choose any number of off-the-shelf, commercial or Open Source intermediaries, caches and libraries to take advantage of REST in HTTP, but the same is not true of REST in SOAP. Especially when we seem to get a new GET-in-SOAP every time we turn a corner.