July 10, 2010
Give it a bloody REST!Another year and yet another way to make software on one box talk to software on another box.
The latest* in a long and ignominious succession of standards and protocols for remote communication between applications is REpresentational State Transfer (or "REST", for short). The title implies that the notion of representing state in some way that can be transferred is news to many of us. Of course, every single RPC standard has to find a way to represent state so that it can be transferred. That's kind of fundamental to it.
REST uses the transport protocols of the web in a very simple and straightforward way. HTTP POSTs and GETs, DELETES and so on. Objects are identified in URIs, much like they are in every dynamic web application ever built. But instead of returning us a web page with our DVD information rendered within, it returns some XML or something like that.
References to other related objects can be embedded in this XML as hyperlinks, so the client application can get a handle on another REST call if it needs to navigate.
Now, the ex-architect in me gets the screaming heeby-jeebies when I see the kind of data-centric architecture that REST seems to encourage (essentially, CrUD for web-based objects, if you think about it). We espouse responsibility-driven design at the object level in code and a "tell, don't ask" style of design to encourage fewer and higher-level interactions between objects as a way of minimising dependencies. REST does not look like responsibility-driven design to me. It looks like web-based data/object stores that can save, retrieve and delete objects via the appropriate HTTP command. I think we will live to regret this. If dependencies at the code level hurt, dependencies at the enterprise level can be lethal.
Honestly, though I'm glad we're pairing it back to something simpler than SOAP, I just can't get excited about this. I've lived through CORBA, COM, DCOM, RMI, .NET remoting, XML-RPC, SOAP and blah blah blah blah blah. And I'm here to tell you that the protocol has never been the challange. Not ever. We cracked that problem years ago.
The problem has always been: what do the messages mean? The challenge in building distributed, asynchronous, high-volume, heterogenous enterprise systems - be they web-based or mainframes - has always been co-ordinating design and testing across multiple systems, written by multiple teams, often in multiple locations, working for multiple organisations, sometimes speaking multiple languages and having multiple cultures.
The glue that binds the systems together is trivial, and irrelevant if those joins don't dovetail neatly together in the first place. SOAP was not a problem.
Know why? Because automated tools generated the glue in many (most) cases. just like it did with COM and CORBA. We never saw it and never cared until it went wrong and we had to fiddle. I see teams all the time now fiddling with their REST interactions, because we're back to hand-rolling the glue for the umpteenth bloody time!
I repeat. The problem has been solved. So stop solving it already and focus on the logic of those inter-system interactions and let a tool do the gluing.
* Although, technically, as old as the web almost. But now fashionable
Posted 1 day, 14 hours ago on July 10, 2010