Two great tastes...

And by Ajax, I am not referring to a minty coloured and burning flavoured scouring powder, but instead some geek-shit.

AJAX is deceptively simple. It stands for Asynchronous Javascript and XML. The basic theory is that you can use Javascript to send 'sub-requests' to a webserver. You can use all your standard Javascript events. As an example, you could display the text of a webpage to a user, and allow them to edit it in place, and use AJAX to send the text to the server to update it, without having to do a page reload.

That is it. Its really easy to work with.. (check out My del.icio.us AJAX bookmarks for some examples).

REST, again seems deceptively simple... I say 'seems' because I haven't had much experience with it yet. REST stands for 'Representational State Transfer' and in my opinion, is really analogous to functional programming. The keys to REST are:

1. It is stateless.
2. It has a well defined set of operations.
3. A universal syntax.
4. Uses Hypermedia

So what does this all really mean?

Stateless

A RESTFUL application shouldn't depend on any state at all. This means no cookies, no sessions. Sounds painful? It really isn't that bad, it just means a subtle shift in how you code your application. In my app Fuchi (which is almost ready for its public alpha), I plan on using a hybrid REST/Stateful application.

See, just because you can't count on state, doesn't mean you can't handle authentication. HTTP has its own built in authentication mechanism (known as .htaccess, but that is a bit of a misnomer). This method just sends the username and password on every request, satisfying the statelessness requirement. Most alternate authentication mechanisms (such as cookie based, session based, etc.) ensure the password is only transmitted once, and use a token thereafter (the cookie or session). So building a hybrid system like this really isn't a problem.

Well Defined Operations

Not penis enlargement operations here. Basically this means using the HTTP request methods: GET, POST; and their redheaded stepbrothers PUT and DELETE, to their proper use. GET requests should only retrieve data and contain no side effects. POST should be used to insert data, PUT requests should be used to update data, and DELETE... well.. you know. It is very similar to CRUD.

Update: I originally reversed the meaning of PUT and POST. It's fixed now. The differences are deeper then 'create' and 'update'. See my entry about PUT vs. POST.

The good thing about using these methods in the way that they are designed, is that you won't run into issues like The Google Accelerator spidering, and activating your 'delete this content' links.

Universal Syntax

That is, everything is a URI. Logging in a user would be handled with the http://www.example.com/user/login URI. Showing a users bookmarks might be handled with the http://del.icio.us/jonnay URI. The great thing is that the URI's can have some really interesting semantic meaning. Take that bookmark URI. If you were to give it a GET request, it would show you all my bookmarks. If you give it a PUT request, it could add one. If you did a DELETE request on http://del.icio.us/jonnay/noparts, it would delete the noparts bookmark. (All this being hypothetical. del.icio.us has a different REST API, which by all accounts isn't actually RESTful. But that is another story. Do a websearch for REST and del.icio.us.)

Uses Hypermedia

No real mystery. If links to other URI's are applicable, use em and link em. thats basically what this means.

You can see how taking all of these pieces of the puzzle can make for a well factored, well defined web application. Each piece being a discreet unit, that has a well defined set of behaviours.

... That Taste Great together

So weaving these two techniques together, can really work well. Lets take the Fuchi app as an example. We could set up a URL called /ideas/idea as a representation of a single idea. A GET request would simply return a list of all ideas. The URL /ideas/idea/423 would return the idea with the ID of 423. A PUT to /ideas/idea would add a new one. A POST to /ideas/idea/423/rating would update the rating of an idea. You get the point.

With AJAX, we can set up a simple little Javascript slider interface, so that we could rate an idea. We can then use the REST API to submit our POST request and handle the update in a really simple way.

In part 2, I will flesh out this interplay a little more.