04/30/08 :: [REST] Who Said Uniform Interface Again? [permalink]
These days, Tim Bray courageously claims "REST, they say, is the way to go". I guess if "they" say, it must be true, as long as Tim repeats it.
Francois Leygues, a French member of the REST community, sent me a pointer to this blog post from Andrew Townley: "URI Opacity Revisited".
Andrew's findings are in line with mine when it comes to explaining how "uniform" an interface can be. Yes, when a human is in the loop, it works like magic, and...
The Big Problem
While all the above discussion about hypermedia applications is great stuff, the big problem with interesting hypermedia applications is that you need to understand what all the links do. With people, it’s easier, but with automated service consumers, it’s much harder.
"Ben oui", as we say sadly in French. You don't have to be rocket scientist to figure that out. I would not be surprised if many more people figure this out after playing 5 minutes with a REST framework trying to implement some server-to-server communication.
Let's take yet another example. I have a "Tennis Court" resource. This resource can be reserved or not (just to keep it simple). So there are two actions, reserve and free. The resource itself can be in two states: reserved and free. How do you implement a reservation system?
a) the CRUD way: the resource representation has an element called <free>, you change its value and you PUT the Tennis Court resource.
b) you POST something somewhere: that's really like a Web Service operation
c) you PUT a "reservation"/"termination" resource with the Tennis Court ID and your ID (at this point you can either assumes that the Tennis Court resource implementation looks up for the latest reservation or termination and returns the content of the <free> element accordingly, or the implementation invokes a) to avoid figuring out the state of the resource when it's queried again).
Solution a) strongly couples the consumer and the provider, b) is business as usual, c) you mean c) is really simpler than a web service operation? no at end of the day there is something called a "reserve" operation (you could also think of a reservation service), and this "reserve" operation has to fly from the consumer to the provider. When a user is in the loop, all this works automagically, and I explained many times why (Andrew agrees). When two software agents talk to each other, then they both have to agree on what a "reserve" operation is and use a "uniform interface" to exchange the intend.
Now, two words on the topic of "URI Opacity". Again, when humans are in the loop, meaningful URL make perfect sense. I don't think it is a good idea to rely at all on this mechanism in the case of server-to-server communication because a service implementation is usually involving some back-end system and it is likely that this backend system will want to take a look at this metadata too.
At the end of the day, programming is really about not being "sloppy", and REST, as a programming model, is the ultimate sloppy technology. Again, when applied to the architecture of the Web, REST is great, terrific, I can't say enough good things about it. When applied to SOA, its principles are terrible. Except for the concept of "Resource", REST has absolutely nothing that is required for constructing a SOA: bi-directional interfaces, inter-actions, orchestration, coordination and assemblies. People like Tim Bray simply don't get it, be sure that they won't be around to help clean up the mess they are creating.
Who said again, that "I was the only one to say what I am saying and therefore I MUST be wrong"? I am simply appalled at the type of things some people in the REST community will do and claim to try to stop any reasonable discussion.