“Serendipitous” Readings

Happened to read an interesting article by Steve Vinoski. After graduating from the school of SOAP I’ve always wondered what was so special about REST that gets the Restafarians so excited but never bother to ask ;-). The article had me looking for examples that validated the benefits of uniform interfaces. (Disclaimer : I’ve always been a WS-* fanboy and haven’t read a word of Fielding dissertation until this week)

To be honest I wasn’t really convinced reading the article that REST was going to solve all of the worlds problems, though I agree with much of whats opined. My sentiments being echoed on this post by Nick Malik

Don’t get me wrong. I love REST. Integration based on REST gives you a great way to share some basic operations and minimize coupling on the operation, but coupling exists in data as well. Decoupling on the operation is step 1, but without similar decoupling in the data, is a partial answer.

However I don’t agree with Nick when he says

Honestly, a messaging protocol doesn’t provide for reuse, serendipitous or not. A data model does. That is the far greater problem.

The reason being data is always going to be the variant and different systems need common data models or at least operate on the same semantics to be useful to each other. But what REST gives you is, once you “agree” on the data (more on that in another post), a fundamentally simple and useful way to pipeline your data across your enterprise systems. Giving pieces of the enterprise a consistent way to participate in “mash-up” of the data that normally would require considerable effort. In the article Steve’s comments on control particularly hit home this point.

Enterprise architecture is primarily about control. Architects put rules in place hoping to achieve application consistency across the enterprise, increase the chances for reuse, and cut costs. Unfortunately, as I’ve mentioned, allowing the proliferation of ad hoc interfaces creates a losing battle for the architect trying to gain buy-in for such rules. Many such architects are SOA enthusiasts who intentionally ignore REST and its elements, constraints, properties, and relationships. Ironically, if applied properly, REST could yield the very consistency and reuse they seek.

I finally do get why REST style can really be useful many thanks to Steve’s comment on this post:

Consider the UNIX shell pipeline. It allows independently-developed tools conforming to its semantics to be chained together serendipitously to create new tools. This reuse is based entirely on the uniform stdin/stdout bytestream interface. Different data formats can pass through the pipeline, depending on the tools involved and the command-line options given to them. The tools, of course, have to understand the data formats they exchange. But best of all, the same power applies to more than just the shell; any UNIX app can open its own pipes and chain together whatever tools it wants to.

I still haven’t got my head around when a RESTful style is more appropriate over a SOAP style of SOA and vice versa, but I do believe that there is a certain class of applications, when built RESTfully, could provide very interesting network effects and value within an enterprise. Many thanks to the debaters for a week that has been full of “serendipitous“, informative and fun reading