Here we go again: SOAP vs. REST

, Feb 18, 2006

It’s been quite some time, so it was to be expected that this particular permathread had to come up again …

Update: We’ve got comments

Don Box started it with this post, which was later elaborated through analogy quite nicely by Mike Champion. Mark Baker has a follow-up, as was to be expected; another one worth reading comes from Mike Dierken. Patrick Logan shares some experience, too.

To paraphrase Don, his key point seems to be that you just have to make up your mind what your goals are, and will pragmatically end up choosing either one or, as a compromise, both options. It’s very tempting to simply agree … but I don’t think I do.

I do believe that on a very high level, the debate is utterly irrelevant. If you’re talking about SOA at an enterprise level, the issues are centered around governance, transitioning, social issues, vendor lock-in vs. standards and best-of-breed approaches … whether you end up doing POX over HTTP in a RESTful or unRESTful way, or use WSDL and SOAP with a code-first or contract-first approach, is not the sort of thing that matters if you’re talking to a multi-billion-dollar company that considers significant changes to its future IT strategy.

But if it comes down to technical architecture, avoiding a decision for one vs. the other by simply doing both seems a little too easy for me. It’s like discussing whether to use Java or C# to implement your software, and ending up doing both; whether to use an RDBMS or an OO database, and support both of them … sure, you can do that, but you wouldn’t. And besides, that’s no way to have end a technical debate, is it? ;-)

The one thing I strongly object to is the one implicitly claimed by by Mike Champion: that somehow, WSDL+SOAP is better suited for the heavy lifting (“the truck”), while REST is for the simpler tasks (“the economy car”). I’ve yet to see any proof that there’s anything that makes WSDL+SOAP more suitable for enterprise-level tasks.

On February 18, 2006 10:36 PM, Mike Champion said:

The SOAP stack of stuff (whatever you want to call it) does include reliable messaging, transactions, security, management, policy, and other inudstrial strength features demended by enterprises. HTTP arguably can be used in secure environemnts where reliability, transactions, etc. are needed, but I haven’t come across very many examples. I usually hear about enterprises using either older middleware technologies that provide these features, and tying them together with WS-*. To the extent they could tie them together with HTTP/POX/REST, it would require a lot of custom work AFAIK.

What part of this do you disagree with?

On February 19, 2006 12:53 AM, Stefan Tilkov said:

I’ve not seen any real-world deployment of any of the more advanced WS-* standards yet, and I have serious doubts that transactions or reliable messaging will be widely deployed soon. At least for now, if you want to stick to interoperable, available and standardized technologies, both the REST/POX/HTTP and the WS-* world offer tools that are usable to solve similar problems (e.g. at the moment, neither reliable messaging nor transactions are widely supported).

But even then, let’s take reliable messaging as an example. I don’t know it extremely well, but I wrote an article about it a while back, and I guess I understand enough of it. I still have not been able to come up with a good scenario of where I would actually deploy it. Transactions is another good example — in those cases where WS-AtomicTransaction is applicable, I’d rather not use Web services at all; where some would use WS-BusinessActivity, my claim would be that you’re better off designing the coordination into your application.

In the end, the question is not whether one “stack” supports transactions and asynchronous messaging and the other one doesn’t, it’s whether you can solve a specific business problems better with one than with the other. I tend to believe that the benefits of the REST approach — a clear architecture and definition, an established set of rules, best practices, constraints, truly universal support, portability, and interoperability — far outweigh the (mostly political) disadvantages. A solution to the same problem, solved in the REST way vs. the WSDL+SOAP style, will IMO be simpler, more elegant, and ultimately more useful.

On February 19, 2006 1:27 PM, Mark Little said:

I know a little bit about transactions and reliable messaging and here’s my 2 cents worth: there is nothing inherently difficult about applying the techniques to REST at all (in fact, some of the earliest work on transactions in WWW was on raw HTTP, dating back before SOAP or even XML was a glimmer in people’s eyes). Plus back in 2001 when I was at HP, we came up with an entirely REST-aware stack (security, transactions, reliable messaging). It didn’t go anywhere, but that is purely a political argument and not architectural.

On February 21, 2006 11:43 PM, pwb said:

“the benefits of the REST approach — a clear architecture and definition, an established set of rules, best practices”

This is where I do not agree. To me, REST seem hopelessly under-described. I want to build a RESTful API but I have little understanding of what that means. And when you take a look at Amazon, the supposed REST poster boy, you learn that it’s not actually very RESTful. I would like to see some work done on describing what a RESTful API set should actually look like.

On February 21, 2006 11:54 PM, Stefan Tilkov said:

Currently, I think the best introductory work in this area comes from Joe Gregorio [1]. One thing that you will notice if you look a little deeper into the REST philosophy is that its proponents actually agree on what the best way to build apps is … unlike the SOA(P) folks who can’t seem to stop arguing (and yes, that includes myself). There is, of course, also the rather formal groundwork [2], and the Wiki is also worth a recommendation.

[1] Look for the RESTful web column articles listed under

[2] Roy Fielding’s dissertation:

[3] REST Wiki

On February 23, 2006 4:06 AM, Mark Baker said:

I also like Roger Costello’s tutorial-style work, e.g.