Recently, Jean-Jacques (JJ) Dubray, a long-time SOA and BPM expert and one of my co-editors at InfoQ, has posted quite a bit about REST — and his posts are definitely not favorable. I don’t really know why, but some of them seem to express the belief that a) there’s some serious hype going on about REST and RESTful HTTP, b) it’s obvious that both REST and WS-*-style SOA have their place, c) that the RESTafarians (including me), despite knowing better, claim REST is a silver bullet that should be used for everything, and d) and have set out on some sort of crusade against SOA. (If I have paraphrases
JJ’s recent posts strongly remind me of those of a certain other gentleman who somehow expects everybody of having hidden agendas and secret motives for doing what they do, instead of doing what they actually believe. I find this somewhat annoying, to say the least. But I have a lot of respect for JJ — so I’m writing this to try to move the discussion towards more rational ground.
First of all — i.e., addressing (a) — I disagree there is a hype around REST. “Huh?” I hear you cry - “is this guy serious?” - Yes, I am, because in fact it’s a tiny minority that knows anything about REST at all. When I go to conferences (QCon excepted), visit customers, talk to business partners or other consultants, 95% of them have never even heard about REST, RESTful HTTP, or some debate about Web services. In contrast, virtually all of them — definitely more than 90% — know about web services. And while some of the vendors have talked about their REST support, this pretty obviously seems to be to ensure the alpha geeks don’t turn to other solutions — I have seen no vendor or analyst throw any marketing dollars behind REST (yet — this may of course change anytime soon). Don’t confuse the blog echo chamber with reality.
As to (b), it’s not at all obvious that WS-* and REST both have their place, at least not from a technical standpoint, and provided what you’re trying to achieve is actually what SOA promises: modularization, loose coupling, evolvability, scalability etc. It seems that most of the WS-* proponents who have spent some time looking at REST, listened to the arguments of the REST proponents but never actually tried it out now take this point of view: REST is suited for simple data-access scenarios, while you need WS-* if you want to do “real” business services. Bullshit. I am strongly convinced that when you look at architectural merits only, every time you convert even a well-designed web services system to the RESTful alternative, you end up with a better system. It would be nice — from a diplomacy point of view — if we could all agree that both alternatives are reasonable, and that the real question is to find the right criteria of when to apply which. But I refuse to agree to such an assertion if I honestly don’t believe there are any cases where WS-* is the better choice (exceptions not motivated by architecture follow). We (the RESTafarians) are not stubborn zealots. We’re just right. Sorry :-)
Of course this was just a little polemic. I actually do believe there are a lot of reasons to choose WS-* — but almost none of them are technical. They are political (e.g. a company may already have spent millions on some WS-* infrastructure), related to costs (switching from existing transactional solutions to REST might require more effort than switching to WS-*), and in some very rare cases — notably security — related to stuff that’s actually missing from the existing RESTful HTTP tooling.
I actually get slightly mad with regards to (c) (we’re out to destroy SOA because we’re evil!). This is so silly I wouldn’t waste time replying, but — as I said before — I like and respect JJ, so I’ll address this point, too. Right now, I doubt that anyone in the REST camp actually profits from arguing that RESTful HTTP is superior. Most of the time, you just get blank stares; sometimes, people get interested before turning back to the crap they get fed by the vendors. Only very, very rarely someone listens and understands the arguments and is actually able to spend some money to have this explored further (i.e. pay for some consulting). It’s much, much easier to go with mainstream, WS-* style SOA if you’re a consultant. And if you make money through reselling commercial products (or alternatively, through referral fees), choosing REST is absolutely counter-productive.
I’m convinced that my company could make more money right now if we simply stuck with the WS-* story. But we don’t make choices for business reasons only (otherwise we’d probably do SAP customizing), but also because we believe we’re delivering good results if we actually believe in what we sell. And you may call me naïve, but I actually believe that the better solution will win in the long run — which means that we’ll be able to reference existing, successful customer projects based on the Web’s architecture when others only start to deal with the WS-* legacy they’re responsible for.
Perhaps REST seems less profitable if you only look at the top-line benefit. I think there are plenty of situations where RESTishness lowers your costs, possibly in equal measure.
ps. …even if your payload has an ‘Operation=”foo”’ tag :)