Caching and REST Web services

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Michael Palmeter's Blog | July 3, 2007   4:07 PM | Comments (0)

I’m really fond of the notion of REpresentational State Transfer (REST) these days, and right now I’m chewing on the relationship between REST and caching and resource abstraction/normalization (take a look at the Wikipedia entry on Representational State Transfer to get a sense of my frame of reference for this blog).

Despite the fact that REST usually involves the HTTP protocol, the data object (representation) in question can be accessed by any means that gives me the basic CRUD that I’m looking for.  This has no bearing on the business logic of my application; I could be using any data access layer that gives me the CRUD operations that I need to allow me to modify that object and communicate the changed state back to the resource.  In a multi-protocol world, this is a pretty powerful concept.  The exact nature of any connector is irrelevant beyond the Data Access API supported by the connector that I am using.  To stretch this a bit further, let’s suppose that a middleware container may, for all practical purposes, be a connector (at least in this sense).  The architecture that leaps to the forefront of my mind is one in which the connector acts as a bridge between the client and the resource, but does not dictate anything whatsoever about the business logic implemented by the resource itself.  To my mind, this makes the notion of Enterprise Data Fabric (a data grid augmented by some resource integration toolchain) very complimentary to the concept of REST services and very neatly appropriate to container-based middleware (like, say Servlet containers).

Now the cases that I’m really thinking of are relatively few, I admit; I’m thinking mostly about applications that have both SIP and HTTP capabilities, like conferencing, messaging, telephony, presence, group list management, and so on.  These are not fringe cases, of course: they’re central to the entire universe of Next generation Networks standardization.  What’s more interesting, though, is the immediate relevance to what is happening in the Web 2.0 world at the same time.  The Telecommunications standards bodies, namely the IETF and all of the other bodies that roll IETF RFCs into their layered specifications, have latched onto the notion of the XML Configuration Access Protocol (RFC 4825) as a generic framework for personalization and preferences management (the ‘User Plane’ of next-generation networks).  What made this such a good choice was not the fact that XCAP is a REST framework, but that this approach exhibits a number of key characteristics which are really important in Internet-scale, high traffic, multi-vendor environments: loose coupling, resource efficiency (communication state is easier to maintain), backwards compatibility with existing infrastructure and scalability (through caching).  It is on the last point where I thin there is something to be considered that Roy T. Fielding’s excellent dissertation considered explicitly.

If we consider the notion that the Data Access API exposed to application business logic executing in a middleware container constitutes a connector (in the REST parlance) then it is entirely reasonable that such a connector may incorporate a caching capability.  The container may also handle identity management, privacy and Service Level Policy enforcement.  It could even provide an environment for resource integration with the cache that hides the complexity of the resource entirely from the business logic of the service.  Now I realize that this is all a bit far from the letter of the REST law, as it were, but my point is that there are elements of REST that can be brought to bear in implementations that stray quite far from strict REST application in the context of the World Wide Web and HTTP.

In this regard, I think that there is a relationship between REST principles and, for example, infrastructure like BigTable, which meets not only functional requirements of end users, but is inherently predisposed to very large scale, high performance systems.  I predict that REST and Data Grids (and the notion of the Enterprise Data Fabric) will emerge as central concepts in the nex big wave of development of the Web 2.0.

Comments