12/09/07 :: [REST] Uniform Interfaces and Application Semantics [permalink]
I have had quite a discussion with some members of REST community (a.k.a RESTifarians). I appreciate the time and the passion some have invested in this discussion. Some have also stopped talking.
If you are intrigued by REST I would recommend that you read:
- the Atom publishing protocol this is by far the most complete RESTful application I have seen documented
- RFC 2616 The Hypertext Transfer Protocol HTTP/1.1 (specially the section on verb semantics, people are still pretty much confused about these semantics) and every one writing a RESTful application has to go to the ritual of VERB-Action binding.
During this discussion I think I have established that:
a) the way the RESTifarians think about resources is incomplete. They simply ignore resource lifecycles and actions. This is, IMHO, the worst aspect of the RESTifarian community, their fundamentalism will set us back 30 years. They are so used to have a human in the loop that deals with actions as embedded links in the resource representations that they don't see it anymore. In service-to-service interactions, the RESTful code that invokes and implements these actions does not rely on a contract. So once you built your service consumer and provider if something needs to change at the contract level you have to figure out a way to communicate that to the other party. Again, works great when a user is in the loop, but this is catastrophic for a service consumer and provider. At the moment Google is updating gmail frantically (maybe it won't be beta anylonger?), everyday I seem to do something differently than the day before. It is annoying but I can still use gmail because I can make sense of it. Now transpose this scenario when no human is in the loop. A uniform interface does not help at all when the "action" interface has changed in any way.
b) RESTifarians seem to be aware that there is indeed an implicit contract but they don't pay attention to it. People like Bill de Hora even think that the order in which operations can be invoked is unimportant. They claim that a contract buys you only generated code and they do not believe there is any value there. (I will write a paper about "Loose coupling revisited, because obviously these guys don't seem to understand what loose coupling means when a human is not in the loop).
c) RESTifarians use HTTP as their middleware platform. The REST uniform interface is a middleware interface. There is no such a thing as an application level uniform interface: only a fraction of the application level interface can and MUST be uniform (I'll be writing more on this topic). This middleware interface is smart(er) and knows about the nature of things that are carried through it, but it is only and for ever a (better) middleware interface. This is why they always go through the ritual of writing down in a document the mapping between their CRUD and Action interfaces and the REST uniform interface.
As I mentioned, there are multiple uniform interfaces possible (ignoring whether it is connectionless or connection-based):
- GET, PUT, POST, DELETE (REST) | Resource aware
- Send, Receive (MEST) | Resource aware
- Send, Receive, Request/Response, Solicit-Response (WSDL) | Message aware
- Write, Read (Stream based) | Not aware of anything
- Create, Read, Update, Delete (RDBMSs) | Resource aware (Tables)
- Publish, Subscribe (MOM) | Topic aware
- Microsoft Robotics team has yet created another uniform interface by mashing them up | I think that it is at least resource and event aware
Whether you consider it smart or dumb middleware, any of these interfaces require lots of code on each side to implement complete application semantics especially the one that deal with resource actions.
I would argue that after reading the HTTP/1.1 Verb semantics, I feel that RESTifarians make a different interpretation of GET, PUT and POST for each resource during the Verb-Action binding ritual. They also claim that a URI is a URI and it has no meaning, it is just a unique character string. In reality they use consistently the URIs to map their action interface, as well as the "search" interface.
I would like people to note that HTTP as a middleware platform is vastly incomplete because it is build on the assumption that a human is on one side able to compensate for any communication error (or application error). For instance, Harry Pierson gave us his solution for implementing Durable Messaging (Harry, could you explain how you do transactions in REST? durability is not enough). Mark Little provides some more perspectives to the RESTifarians in the context of compensations (and transactions). I must admit that Harry is hilarious. Harry says that (and this is not innocent coming directly from "the voice" of the architects at Microsoft):
like many I've become disillusioned with the WS-* stack over time and see REST as a viable alternative to all that spec-driven complexity
The first thing he does is to point us to a "spec" to solve this one problem. Who do you think you are fooling? Turns out that this spec is written by Dale Moberg and Reed Drummond who happen to really know the difference between writing a spec and writing a blog post (which is an extremely rare capability in the REST community). Many might think that we travel the world, wine and dine all day and occasionally we spit out a cryptic document (making sure that the least amount of people can understand it). Well, there is actually some truth to it, these are often the same people (a.k.a Roman Generals) that only think of technical committees as being a (political) battleground that is going to serve their career. but at the end of the day you also have hundreds of people that are passionate about sharing and understanding and ultimately advancing the state-of-the-art of software engineering, if not computer science. Harry's post is an insult to these people that have often made important personal sacrifices to contribute to this work that benefits all.
d) RESTifarians often use an Amazon as their showcase. I would recommend that you look at this presentation from Amazon's CTO. In the middle of the presentation he goes through the history of the platform and explains how they achieved the kind of scalability they needed (that most people don't need) via RESTful services. I would challenge however the RESTifarians to convince Amazon to explain us how they use RESTful services in service-to-service interactions.
I think at this point for me the debate is closed, I don't think the hard-core RESTifarians can be convinced, they do not believe in contracts and assemblies as core technologies that enable a higher degree of loose coupling (and verification). I explained in this article how resources, actions and assemblies form the foundation of a loosely coupled process centric programming model. This is also the nature of wsper. So if you have two different set of beliefs and two different problem contexts, I don't see why we would agree on a common solution. Actually, it is more "they agree" on anything than "I agree", because as far as I am concerned I am all for making resources explicit (all the way) and I don't mind smart(er) middleware as long as it lets me implement application semantics easily. REST alone as defined by the RESTifarians does not fit in this category.
I am however extremely distressed at what I consider an irresponsible attitude from a small group of people that want to impose their diktat on the industry with more than questionable arguments. I appreciate the fact they do not want us to spend money on expensive middleware. I support that aspect of their initiative, I often advise people to think clearly and precisely about the quality of the communication infrastructure they need. REST works because most often there is a human on one side that can understand that the other side is not in the state it wishes it to be. A human can deal with unreliability far better than a software agent. State alignment between a service consumer and a service provider is one of the hardest thing to achieve, and HTTP won't give you that "out-of-the-box".
As a middleware platform, REST is missing orchestration, assembly and choreography concepts (which combined offer an unprecedented composition capability, no middleware platform ever achieved this). RESTifarians simply don't get it, they never spent the time to reflect on these concepts. I strongly believe that they have missed what happened in the last 3 years in the SOA / WS-* world. I can appreciate that around and before 2004 some lost faith in what WS-* was going to deliver, but I strongly recommend you go back an look (most of you still don't understand that WSDL offer a bi-directional interface with both inbound and outbound operations)
Worse, RESTifarians (because REST mixes application and middleware semantics) want to teach us how to construct an information system in a way that will negate any progress made over the last 30 years.
For me REST + WS-* is the way to go (even if it means some things have to change in WS-*), both WS-* and REST can learn from each other, for the greater good of everybody, without killing each other. REST alone is a dead-end. As we speak, people are already building REST-*, and they are totally unappreciative at how complex creating a specification can be (they have never been in a standard committee). At the moment they simply exchange posts, tips and tricks, and voila. It will take another 10 years to transform these posts into specifications from the time Microsoft, IBM, SUN, BEA and Oracle will get involved. In that case, see you in 2017...
In conclusion, I would like to express that fundamentalism has always and will always be on the path to progress because it demands to apply consistently the same solution(s) regardless of the problem at hand. I often speak of the "fundamental problem" or the "fundamental question". You will never catch me saying "the fundamental solution". This is an oxymoron, for any given problem there are only good and bad solutions.
Since the advent of the web (and thank to REST) we have understood that monolithic information systems can be thing of the past. (SaaS, IMHO is perpetuating monolithic architectures.) The value of composite information systems is compelling not just for scalability reasons, but also for pure economical sense. For instance a composition information system should be able to reuse assets that can't be replicated on-premise (Google Maps). Because composite information systems are desirable, middleware and application semantics need to come closer and offer the best layering possible (distributed objects being the worst layering possible). The RESTifarians are sending a strong signal to the WS-* community, ignoring it would be being just as fundamentalist as they are. A door is opening, driven by strong value. I am actually predicting in 2-3 years time people will seriously question the value of "desktop-based operating systems" because their "personal resources" (and their lifecycles) will be exclusively handled by composite applications. Which side of the door to you want to stay? The RESTifarians (and some vendors) are trying to convince us to sweep a decade of painful progress under the REST rug. Yet, we have never been closer to opening that door. I am sorry to say that your irresponsibility is only driven by ignorance and belief.
Now, thinking that anyone has "broken the code" of composite applications in 2007 is premature, there is however no turning back from this point.
P.S.: I have never really talked about how hypermedia links related to "resource associations" but I spent quite a bit of time to think in this direction as well. It will be part of an article I am writing.