12/22/08 :: [RESt] sUBBU'S aRTICLE [permalink]
Subbu wrote a very nice and courageous article on "Describing RESTful applications". I agree with every bit of it. If it was still necessary, it shows unequivocally that there is no serendipity in "reusing" ... "resources".
I expressed many times that there are good things in Resource Orientation but at the end of the day, RO brings nothing new to the application model table. RO, alone, is a step backwards -a major step backwards- when building connected systems.
When Subbu invited me to review his article, I suggested to complemented with a metamodel because, IMHO, we can't introduce a contract without introducing a "Resource Type" (this is in essence what Subbu calls a "resource" in his contract definition, but I find that confusing). You can call a resource type a "URI Template" if you want but at the end of the day, the coupling one-endpoint-one-resource (instance) is terrible for factoring business logic: you have no other alternative than introducing a resource type. Things get quite confusing when in addition you have to encode action semantics as resources which have their own type and representations.
You simply don't attach business logic to a resource instance (in general), you need a resource type for that, which is missing from the REST model (which in the first place was never designed for doing the kinds of things. Can we also think that people are going to put up with adding links to every single resource representation they exchange all the time? How can these links remain relevant in concurrent scenarios? The pattern is interesting and can even be useful in specific scenarios but what's the point? just to be "RESTful"? RESTfulness at the application level is an illusion, REST was never designed for that. The Web is RESTful because Roy designed an application protocol aligned with the lifecycle of Web resources. In the enterprise world, where the lifecycles are different and varied, the application protocol does not work anymore. Subbu is suggesting to fix it with links, why not, but what for?
Interestingly Subbu also defined a proprietary ID mechanism reinforcing the idea that a URI is not generally used for identity purposes. I would have preferred a "link" to a unique resource identifier.
I had also given Subbu the feedback of how important contracts are to versioning, and in turn how important versioning is to reuse. Most of the RESTafarians, including Tim Bray, simply don't get that.
So where are we today? we already lost a couple of years (we could have aligned RO with SO instead -or vice versa), and we probably will loose another couple more until there is enough feedback to show that REST brings nothing new, that REST is hard to use because of the coupling one-endpoint-one resource (which is actually many endpoints-one resource). Even people like Doug Purdy are completely confused about producing a simple RESTful sample. Ultimately, 80%+ of the people will end up CRUDing. Thank you, what an achievement of the distributed computing intelligentsia.
It is easy to understand that as soon as you introduce a Resource Type, you are in SO territory (at that point, you left Roy's REST a long time ago) and as soon as you are in SO territory you start asking why should you put up with URL syntaxes and malformed query languages or why should you give up outbound operations or orchestration languages which are key differentiators from antiquated distributed computing technologies and essential concepts to build connected systems.
It would be a much more interesting exercise to narrow down the concepts needed to build connected systems and establish a clear articulation between them (resource, services, events). But that would be way too easy, being "religious" is so much more fun, not.