This Isn’t The Droid I’m Looking For

Since David Ing responded to my REST/CRUD/CRAP entry on his blog, I guess that means I respond to his response here, right?

Actually, this is going to be very short[1] because I mostly agree with what David wrote. For example:

If we say stuff like ‘REST shall/must replace all foolish WS-* SOAP systems (insert Nelson-style HaHa here)’ then we are just repeating the same lessons as before – One size won’t fit all and there is no One Ring to Bind Them illusion in REST as well. If you have something complex that fits the WS-* style then maybe REST isn’t the droid you are looking for.

Of course, this begs the question “what is complex?” David described complex as “long running transaction updating multiple distributed stores”. Personally, I’d replace “stores” with “systems” and I hate term “long running transaction” so I would have written “long running operation” or “business process”, but grammatical nitpicking aside that certainly seems like a fair description. Certainly, most of the scenarios I’m looking at in my day job could be described as being long running and updating multiple systems. David says later that he thinks “a lot of apps don’t need to be modeled that way”, but I’m not aware of the alternatives so I’ll let him expand on this on his own blog. I’ll try to get to writing about my thoughts around protocol state next week.

I did disagree with this one point:

We may say REST is really about a protocol state and not CRUD, but unless the rest of the world gravitates to that view then I’m afraid it just won’t be. If, say, through some ongoing groundswell of common usage, people start modelling entities as dereferenceable URI’s and using POST to do Create and Updates, then REST will be about CRUD by default. This is all very unacademic and unjust, but thems the breaks peachy. The lesson from SOAP is not to fight it by trying to re-educate the masses after they get a perception in their head.

I think it doesn’t really matter how the rest of the world gravitates, it only matters how you as the the service provider choose to expose your service. If you’re doing something simple like ATOM publishing, you can probably get away with REST as CRUD. (Would that be hi or lo REST?) If you’re doing something more complex, either in terms of being long running or needing multiple updates in one atomic operation like Tim’s airline example, you’ll probably need to gravitate towards REST as protocol state. But can’t the two models can co-exist nicely, even in the same app? No re-education required.

Update: – From Fielding’s Dissertation: “REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified”. My point exactly.

  1. Wow, this post wasn’t that short at all. Can you imagine how long this would have been if I had mostly disagreed with David? ↩︎


To save valuable internet space, I'll just comment here - no one wants the tubes blocked any more than they are: 1. 'I think it doesn't really matter how the rest of the world gravitates'. Ooo. Three words Harry, in, ter and op. The nearest thing I had to a point was that if your interpretation of REST is so very different to mine (it isn't, but lets go along with this), then aren't we making harder to 'walk up and use?'? The world is full of cutting-edge inspired ideas that no-one now has a clue on how to maintain (or even talk too). Imagine if people rush to REST and make it an overnight/14 year success with PUTs/DELETE's on some Entity driven crusade to emulate WebDAV with everything they can find (or APP gData styling it all), then they may find your entityless system harder to interop with (or even to grok) - especially where it's so early in have some formal description of what your valid 'interface' (states) are? 2. Agreed about transaction/bizprocess thing - that was a 11 keystroke spelling error that I must stop doing - the keys are right next to each other though. 3. We need something like Godwins law, i.e. when anyone ever pulls out a Fielding Disseration link then all bets are off... ;-) One important point that I forgot before is related to what Dare said about Mike Champions WS-* vibe, are you really *sure* you want to use a Web protocol for something that might not be actually used on the Web? Anyway, typing too much, I should blog at home...
Two responses to point #1 above: First, as I pointed out in my update, Fielding specifically allows the author to choose resource identifiers as they see fit. So I might argue (if it came to down to an argument) that maybe you're not "doing REST" if you can't interop with a REST as Protocol system. Second, in theory people may find it harder to grok, but in reality are we really worried about that? Is Tim's airline example really that much harder to understand than Atom Publishing? I don't think so.
Trying hard to disagree with you here Harry, but in the interests of the discussion then how about?: - If I had a wonderful Doughnut Atom Publishing Protocol (APP) based resource on the web that you wanted to use as part of your DeliciousThingsToEat composite app, then don't you have to now treat me as a special case, i.e. I'm not expecting to return a getDetails URI in *my* response - are you going to have to write a special adaptor to make me fit in as an in-between state for your 'controller' of your state machine? The world gravitating to the PUT will make a little awkward for you to add to your application with the resources in systems that you didn't write? If you don't intend to 'promiscuously mashup' from outside resource-based services (maybe for an internal system that could be Service rather than Resource orientated?) then this point is moot. - I think the butterflies in my tummy about this issue may be related in that it smells a bit like the days of SOAP Doc/Lit vs RPC/Enc chaos, (Cough - Hey, I know how about Basic Profile 1.0 for REST usage!? Shudder!). The 'you say POST and I say PUT' chaos is probably a way of life, and maybe if it took us 4 years to figure out not to tunnel the GET through a POST it might take a similar amount of time not tunnel the PUT through POST either. :-) - Unless Roy is going to come around my house and fix the code for me when I get the wrong interpretation of REST, they I don't care/mind what he wrote on the resource-intpretation issue. :-) I could also make an argument that the Real Web isn't really REST based in practice either - and no-one took *their* REST license away... (we should blog this, it's far too interesting a topic to live in comments)
Ug. Couldn't resist. Updated the blog here: Sorry.
Me too.