This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

RESTafarian SOA killers?

Stefan Tilkov,

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.

On November 12, 2007 8:38 PM, Erik Johnson said:

And if you make money through reselling commercial products (or alternatively, through referral fees), choosing REST is absolutely counter-productive.

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 :)

On November 12, 2007 10:13 PM, Bill de hOra said:

“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”

I’m getting asked about REST a lot from outside the usual circles. It’s kind of startling.

“I doubt that anyone in the REST camp actually profits from arguing that RESTful HTTP is superior.”

Then again recommending REST is no longer a career limiting move the way it could be a few years ago :)

On November 12, 2007 11:11 PM, Stefan Tilkov said:

Then again recommending REST is no longer a career limiting move the way it could be a few years ago :)

Yes, I agree — awareness is rising, but I still consider “hype” to be an extreme exaggeration.

On November 12, 2007 11:47 PM, Paul Downey said:

State of my corner of the world: expect genuine irritation from business types when they realise that Web services ARE NOT on the Web and that said services don’t fit the world of widgets and mashups. Most every savvy techie I meet now gets the value if Web exposures and recommending WS-* seems to be, well, a well understood as an overly complex mechanism designed to sell tooling. Even when you could get the stuff to work, often by shipping SDKs, not WSDL/WS-Policy, it’s brittle, and doesn’t have that wide a reach - try using WS-Security from a bog standard server running PHP 5 (most ISPs ship with SOAP and dsig turned off). However, as you point out, the sunk costs for many companies are enormous, and for that reason, they’ll be with us for some time to come, increasingly buried behind Web servers.

However, many of those enterprise types who now want REST, not SOAP, seem to think metadata, in particular “description” and “orchestration” is still required. It seems to me that folks want REST but don’t yet have faith in the hypertext as the engine of application state.. but we’re working on that ;-)

Anyway, I promised not to gripe about SOAP (v) REST anymore, “The Web is Agreement” was supposed to be my last word on that, heh.

On November 13, 2007 9:42 AM, Stefan Tilkov said:

ps. …even if your payload has an ‘Operation=”foo”’ tag :)

Ah yes — I meant to reply to that for a long time …

On November 13, 2007 11:19 PM, Steve Jones said:

Stefan, one of my biggest concerns is the “belief” bit around REST. Like you say its a small, vocal group of people preach a given set of principles as being “right”. Like all IT fundamentalist approaches it takes the solution to a single set of problems and trys to scale it up to everything. The “belief” is the agenda.

Let me be clear. REST (as in WWW/HTTP) works in lots of places, especially late aggregation (browser, mashups) and rendering to people. WS-* works (today) in lots of places, especially B2B and system to system integration. FTP works in places as well, for instance shifting large files for batch processing, other things work in other places.

One size doesn’t fit all and no one technology or approach represents a silver bullet.

On November 14, 2007 9:30 AM, Stefan Tilkov said:

I’m not religious, in no sense of the word. Roy is not Jesus, the dissertation is not the bible, and REST is no silver bullet.

Saying that I like Macs better than Windows PCs doesn’t make me a Mac zealot. Considering REST to be superior to WS-style technical SOA doesn’t make me religious. Both you and JJ seem to believe that just because I consider RESTful HTTP superior to WS-* beyond simple CRUD scenarios I believe it’s appropriate for every scenario. It’s not. But it’s useful for way more than you believe — specifically, building a “business application” including “business semantics” in a REST-style meets high-level SOA goals better than the WS approach.

On November 14, 2007 10:42 AM, Steve Jones said:

See there you go being reasonable again :) I wish all RESTafarians I came across were as educated and reasonable.

I’m still waiting for the proof around the business level REST implementations, I’ve not come across one in an enterprise environment and specifically in a system to system scenario.

My question still remains on REST though, the question should be “why isn’t WS-* good enough” rather than this continual search for a better wheel.

On November 14, 2007 11:17 AM, Stefan Tilkov said:

Good enough? Well, why isn’t sending fixed-length records over TCP using plain sockets not good enough? Or exchanging XML files via FTP? Or using CORBA? You know I like to have discussions at both a high-level as well as a technical one, but if we’re discussing the merits of different technical architectures, it’s surely allowed to discuss technical aspects? ;-)

On November 14, 2007 11:48 PM, Mark Baker said:

Steve, I’m curious which RESTafarians have taken a position other than the one Stefan explained above, that REST is no silver bullet, just far more general than believed by SOA/WS proponents.

On November 15, 2007 10:19 AM, Mike Glendinning said:

Far be it for me to be provocative and throw fuel on this fire, but wouldn’t any form of “system to system” communication violate REST’s “client-server” constraint. From Fielding 5.1.2:

“…separating the user interface concerns from the data storage concerns…allows the components to evolve independently…”

This could be why Steve hasn’t come across REST in typical enterprise application integration scenarios.

On November 16, 2007 8:34 PM, Stefan Tilkov said:

Hi Mike, I’m not entirely sure what you intend to say. The dissertation talks about “user interface” clients that need to evolve independently from the server. This need seems to apply to SOA “consumer”/”provider” at least as much - doesn’t it?

I agree that many people (wrongly) perceive Web architecture to be applicable to UI clients only, and this is why we don’t see RESTful HTTP being used for integration much (yet).

On November 18, 2007 12:43 PM, Mike Glendinning said:

I was suggesting, somewhat provocatively as I haven’t had a good argument for ages, that server-to-server interactions break the client-server constraint of REST.

Of course you might say that in any given interaction, the server is merely performing the role of a client and that as long as we make sure there is no circularity in the dependency graph of systems, we’ll be allright. In pure engineering terms, this is undoubtedly true and corresponds to what has been best practice in distributed systems design for many decades.

But Fielding doesn’t say this and is much more explicit in wanting to use constraints to drive the design of a “principled” architecture. And he wants user interface and data storage concerns to be separated through the client-server constraint (1).

Simply put, if your client is doing data storage (2), you’re not doing REST. This probably discounts most enterprise application integration scenarios.

Oh come on, Mike, I hear you say, you’re not expected to take the constraints that literally. We routinely ignore the “hypermedia as the engine of application state” constraint, partly because nobody understands how to apply it, and often fudge the “uniform interface” constraint because in fact not all resources behave in the same way. But who cares? We’re just engineers trying to build working systems.

Fair enough, I would respond. I am an engineer as well. But why make such a fuss over strict adherence to “constraints” and “principled design” if in practice you’re going to play fast and loose with your definitions in the pursuit of working systems?

Maybe I should write a thesis entitled “pragmatic engineering principles” and then berate you all for not following my rules to the letter, to hell with whether they actually work or not :-)

Footnotes: (1) Let’s leave aside for the moment Fielding’s misunderstanding of what exactly constitutes a “client” in REST as we’ve discussed that before. (2) Remember also the “stateless” constraint.

On November 18, 2007 8:08 PM, Stefan Tilkov said:

I believe the constraints can be taken literally, even in integration scenarios (although obviously they don’t have to all the time). I agree exactly with your point - the client and server aspects are just roles. I don’t ignore the hypermedia constraint, on the contrary - I think REST derives a lot of its value from it. I also strongly believe in the uniform interface constraint’s value (exactly because of the hypermedia aspect). And what does the client’s storage of data have to do with the stateless constraint? In my reading of the dissertation, the client is perfectly allowed to keep (application) state.

On November 19, 2007 9:41 AM, Mike Glendinning said:

Hmnnn. In what circumstances don’t the REST constraints have to be taken literally?

And I wonder how many of your present REST designs have the client application state driven only by hypermedia documents delivered from the server. Not many, I guess. The current state-of-the-art appears to be about sprinkling a few URIs in returned resource representations, but still having the state-change decision logic hard-wired in the client.

The client-server and stateless constraints are (to some extent) mutually reinforcing in that it appears that clients MUST NOT store “data”, but can store session/application state, whereas servers MUST NOT store session/application state but may (perhaps MUST) store “data”. Actually, Fielding is very vague over exactly what he considers “session state”, “application state” and “data”. I seem to remember we had a similar debate on the Yahoo SOA list a few months ago.

Probably more than 99% of current web applications violate these constraints, thanks to all those “session manaagement” features of application servers.

On November 21, 2007 10:51 AM, Stefan Tilkov said:

I wonder how many of your present REST designs have the client application state driven only by hypermedia documents delivered from the server. Not many, I guess. The current state-of-the-art appears to be about sprinkling a few URIs in returned resource representations, but still having the state-change decision logic hard-wired in the client.

True, most of the time the client drives the state changes, using the URIs, but definitely not only them. I believe there’s a lot to be gained from exploring this further — I haven’t yet seen a client-side REST approach, let alone programming model that really exploited this. At QCon, Jim Webber suggested there’s a need for a more declarative way to do this, but clearly this is at the moment just a research area.

The client-server and stateless constraints are (to some extent) mutually reinforcing in that it appears that clients MUST NOT store “data”, but can store session/application state, whereas servers MUST NOT store session/application state but may (perhaps MUST) store “data”.

IMO, in a machine-to-machine scenario, both partners are likely to have their own resource state and application state — where one can become the respective other if you change the point of view. That is, my current state of usage of your resources — i.e., my application state — can be a resource from my POV, and vice versa.

Probably more than 99% of current web applications violate these constraints, thanks to all those “session manaagement” features of application servers.

Yes — which they take great pains to store persistently to support clustering (instead of putting them into the DB in the first place).