12/23/07 :: [REST] REST and inter-actions [permalink]
Two weeks ago I was trying to summarize my debate with the REST community. Several posts later and many emails, my position has not changed.
1) I like REST, REST is brilliant, this is one of the best technology designs I have seen in a long time.
2) Even though REST is brilliant, it is incomplete. It has opened the way to make "middleware" aware of application semantics instead of remaining confined to "distributed computing" semantics. Prior to REST, all the bright minds of distributed computing could think about was "remoting": send/publish a message, remote a function call, remoting a method call... REST has showed us that there is a better way, a far better way to enable software agents to interact with each other. "Interaction" is the key here. The things that interact are not merely "sending a message", "calling a function or a method". Things "interact": the "things" and the way they "interact" represent a key understanding to successfully build "connected systems". Ultimately interaction leads to composition. The composition introduced by the Web and REST lead to presentation composition (mash ups). Other forms of composition: process and information are valuable too.
3) Because REST is incomplete, the REST community is adding here and there what they need, APP is taking the role of SOAP for instance. They don't really yet have a security, transaction and reliability story, they will one day. Can the REST community design REST-* to be better than WS-*? yes, I believe they can (not hard, just be careful who you bring on-board...). Do they underestimate the task? yes, I believe they have no idea of the task at hand. The caveat to what I just said though, is that the REST community is trying very hard (too hard?) to avoid the concept of "service" to manage "network data objects". The only reason they are trying so hard to hide services is to avoid having to define "contract" of this service. They are still in the belief that "interaction contract" means "remoting" they have missed point 2) above. One day they will also realize that they need a "contract" and on top of it an assembly mechanism.
4) Where is the REST community today? Talking with Subbu, I think I understand the disconnect. He works for Yahoo (same would be true for Amazon, Google, Microsoft Live...). For these people, who operate vast data centers, every CPU cycle counts. It speaks directly to their user base: if yahoo is sluggish people will switch to Google and vice versa. I, on the contrary, work as an IT architect. In my world, a server is not much, many large corporation critical systems can run on a couple of servers (for redundancy). Virtualization technologies let me handle seasonal peaks easily, what I care about is "weeks of developers", "risks", "downtimes" (or how my information system can deal with unavailability). CPU cycles is way, way down there for most of what we do. To sum it up, Yahoo cares about the "response time" to a "request" from a "user", I care about the "response time" to a "request" from a "business partner". I wish I could also give him or her a "sub-second" response time, but If I can offer response times in the order of a couple of hours for hot fixes, days for changes and weeks for new stuff, I am going to make him or her really happy. Believe me, caching responses is way, way below the radar (and the way people implemented REST's caching mechanism can't even reliably "represent" stock quotes or allow me to navigate pages when I am offline - how stupid are those two things?). For IT, If I can reuse a piece of code 2-5 times, this is a tremendous savings: imagine the cost of duplicating assets in IT? re-implementing, re-testing, integrating? how about maintenance? now I need to apply my changes to several code bases in different technologies?
So what is missing in REST?
1) (Re-)Establish XML as the foundation to exchange information, using XSD to manage both structure and extensibility
2) Define contracts based on extensions to a uniform interface that support bidirectional interaction patterns based on a basic composite application model. This interface MUST be bi-directional: in-out and out-in, in and out. It does not sound like much but this is essential. I know, the old remoting guys have done the best they could to lock down Web Services in uni-directional pattern: in-out and in (they have so much to loose), but that's a dead-end, and unfortunately, the RESTifarians are falling in that trap too.
3) An assembly mechanism that would let me wire components together to achieve a given interaction definition
4) A new programming language designed for "interactions"
5) Sure, and Transaction, Reliability, Security (REST has addressing capabilities) are needed too, but that's a given, REST is not going to avoid these.
The problem with the REST community is that they missed the turn and they are not on the path to build 1,2,3 & 4 because of the understandable distrust they have had for remoting technologies and that WS-* has somehow corrected. How could that have happened? you remember the little story about how Web Services were started to compete with ebXML in the B2B space? Guys, in the Ganesh's style, I have news for you. There has been a big composite system running for decades: EDI. The remoting guys had no clue but they introduced a few "features" to look like they were doing B2B: namely bi-directional interactions, XML and WS-BPEL. They tried to lock down outbound operations in WSDL with WS-I, but 2 years ago IBM introduced SCA to finally enable the binding of outbound operations, and BPEL of course is full of outbound operations ("invoke").
Now, WS-* has still lots to learn from REST. REST is packed with really good ideas, for instance things like "media type" mediation. This is a fantastic concept, but IMHO, it could be generalized further by the notion of "role" with respect to an interface: "I am invoking this interface, on this resource, with this role". Such that when I get an employee URI, I don't get to see all the employee resource content. My "role" commands the representation that I get.
Nothing that I have learned makes me think that there is anything bad about REST, I am just warning the RESTifarians that they (not REST) are heading to a wall, just as big as remoting. Just give me some time to publish this article on "loose-coupling" and hopefully, we can continue the discussion afterwards.