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.
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?