Grasping REST

I have been thinking about the old days, where it was all raw technology and trends. An important trend I have picked up on is the formalisation of the notion of opening up the pieces of an application, called REST. The Wikipedia article is pretty comprehensive, although I found the combination of Rest in Plain English from the RestWiki in conjunction with some examples more tangible.

For me, the contrast of REST with RPC is meaningful (it was what we used to do right?). I like the perspective of thinking about web services as a top-down approach with pre-designed contracts mediating interaction. REST seems to promote a simplified bottom-up perspective, allowing complexity to be defined as aggregates when and where it is needed. Further, the notion of 'application pieces' (resources) as nouns which can be presented and manipulated with verbs provides a nice pattern compared to dragging procedural calls out into the open. Allowing users to define the use of a set of loosely coupled primitives comes into line with neo-web notions of mashups and allowing users to locate and refine the value of your data (classic web2.0), and I presume that's the point.

It is interesting how business is now driving this institution to formalise the approach, specifically with regard to the need to integrate it into SOA. So-called Web Oriented Architecture provides an effective tool for the enterprise to internalise the notions, although I'm not so sure that they are applicable. Business is where you want heavy lifting with well defined contracts like web services, lightweight interaction and 'application as the platform' doesn't make sense unless you're opening it all up to the wild (or you're massive!). The point is, the enterprise market is seeking alternatives to the over-complicated state of SOA. It appears that commentators are suggesting business heed the lessons of "being open" and "simplification" and are not suggesting a disregard web services completely. Perhaps most important is the observation that it's not "REST or nothing", and that partial (weak and implicit) adoption has shown to be good enough even on the open wild web. The explosion of mashups happened (is still happening) using scraping and RPC-based API's without explicit REST, micro formats, or automated tools.

The obvious point is that acknowledgment of the approach and exploitation where appropriate must become a best practice for architecting new web-based systems. The Ruby on Rails community have identified this and have made REST a foundational principle for the platform going forward. This is good for the approach as the RoR community of early adopters will quickly anneal the how's and when's, and progress is being made. I seem to remember a similar situation with the adoption of AOP and the early adopters annealing the applicability in appservers and frameworks.