Wednesday, August 31, 2005

AJAX and REST

Why I think AJAX breaks REST "The Web is a hypermedia application. According to REST, following a link you should be transferred to a state representation which is associated with a particular URI (in the case of the Web, a URL). As it happens, together with that state representation we may also get some code that our hypermedia document viewer (the browser) executes. Depending on the interactions with the end-user, another program, the environment, etc. the executed code may make use of asynchronous calls to change the represented state that our viewer has loaded. It does so by usually fetching more state, possibly in a REST-friendly way (i.e. HTTP requests). However, during the user-application interactions, the URI remains the same even though the state representation that is rendered on our screens has obviously changed. Now, some AJAX applications may force a change in the URI effectively simulating a state transition but most of the ones I have used do not."

REST is a way to expose services and AJAX is a way to write client software - they can't really effect one another.

AJAX can break the ability to save client state, in exactly the same way that frames do (complete with breaking the back button). AJAX applications may or may not update the URI in the browser to represent the current state it is in, but you can certainly write them so that they do (just like frames).

In a RESTful approach the architecture puts restrictions on the server, not how the client represents its current state:"...each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server."

Also, AJAX - beyond the buzzwords.

Update: Why I think AJAX breaks REST continued "What I did say is that the use of the AJAX approach to building distributed applications, or even just client-side ones, encourages a move away from the REST principles and that those building distributed applications should be aware of that...We just can't call all the good things out there RESTful."

I take REST principles to mean providing URIs to represent the current state they are in. However, I don't see browsers or client side applications as being RESTful or not. Tabs, frames, pop-ups, running code in Flash, Javascript, and applets; all of these things are not represented by the URI in the toolbar.

The only thing that's guaranteed in REST is that a client changes state when it goes to a URI (the representation of the state) on a server. How it represents that state is entirely up to it.

There are good reasons why everything just isn't represented by a URI, but I do think that more things should be. One is space requirements, imagine GMail storing every state that your mail box is in and providing the ability to go back and forward (very Xanadu perhaps).

No comments: