Only Send What You Need

Managing RESTful AJAX operations is an open problem. While I say that <a href=/asynchronous-rest">aspects of managing HTTP requests, and designing UI feedback cannot be understood in isolation and must be integrated</a>, I still think there are two distinctive and separate issues to consider.

For starters, HTTP has always been stateless, that's it's fundamental form. So in some ways, talking about asynchronous representational state could be pretty meaningless, but it becomes far more interesting when we consider the differences between "pages", "services" and "resources".

The basic concept of the HTTP protocol is of a set of request types - the verbs that act on the nouns representing each resource. The fundamental format of a resource is a page, but practically, it could be anything. In contrast, the concept of a web service is often related to the notion of a remote procedure call, treating HTTP as the way to transmit access an object and return the results of a method, usually without needing to consider the URI as representing an actual resource. Remote procedure calls mostly return generic data structures or a "message", usually in XML format.

In AJAX land where the dominant metaphor of pages is changing towards one of "containers", there are two kinds of requests:

1. Requests that load data structures or content to be displayed in the user interface
2. Requests that modify and store content on the server

I haven't yet seen much discussion that attempts to separate the distinct issues that arise from these two separate aspects. I think the first of these aspects is pretty well understood - the notion of "only load what you need" is familiar to many developers, but it's the second that interests me the most.

GET and POST are so overused, it's often easy to forget that PUT and DELETE have the potential to be useful too, although I think that the dominant trend has followed a pretty much ineviatable path of least resistance in browsers and server languages, being largely responsible for blocking the potential ascent to a RESTful nirvana.

If http://mysite.com/item/my-title was the URI location of a particular content item, a GET request should return a standard HTML page, unless the request specifically instructs the server to deliver another content type (plain text, javascript, or XML). To extend this further, the application should enable the ability to make a POST or PUT request to this URI. In many implementations I've seen, the application will break if a POST does not contain an exact set of particular fields. Where the overlap of AJAX and REST gets exciting is the potential for making use of a server controller that is smart enough to trigger a unique persistant update based on the particular HTTP headers and fields sent with the request. For example, you could send title=A+changed+title or title=A+changed+title&description=A+new+description to the same URI, and expect a coherent update to occur in each case.

So what if a web application did expose a full range of structured data through a pure URI format? Whether AJAX or not, this approach changes the notion of a resource from representing a page, or a stream of structured data, towards representing a synthetic object. The cannonical notion of these objects is the noun "item". The noun "page" would be another one of these objects, as would "book", "quote", "note", "event", and so forth.

I'm interested in developing this kind of resource framework at a more fundamental level - a meta-vocabulary for constructing content relationships - although to a greater or lesser extent, all dynamic sites do this anyway. What few sites do however, is expose their vocabulary directly through the URI. I'm starting to see some interesting possibilities.