Take A REST (The Theory)

Since Rails 1.2 there was a chat about REST and what it means for us (at the end of the food chain). Before giving some practical examples on how to use it in Rails in a later paper I'd like to write some notes about its theory.

Once upon a time ...

No. Seriously. In 2000 Roy Fielding launched REST in a dissertation. REST stands for Representational State Transfer, which naming includes all about what's going behind the curtain. I try to define each single word in a short briefing in hope that nobody will hurt me for its oversimplification:

• Representational stands for: Every resource is represented by an own unique URI (so it is a mapping URI == resource/data/HTML/object/PDF/whatever_you_want_it_to_be)
• State means to have some HTTP verbs, which job is to declare what to do with this resource (I will describe these verbs later)
• Transfer is self-explanatory (isn't it?)

Please let me emphasize the Representation thingie once again: an URI represents a RESOURCE. It's not that I like wagging forefingers, it's because of the later understanding why Rails generates such routes.

O.K. now I will name these HTTP "verbs" (as I promised; and I always keep my promises ;) ) In the orignal HTTP specification there a declared the following request methods:

1. GET: get a resource
2. POST: update a resource
3. PUT: create a resource
4. DELETE: delete a resource
5. HEAD: returns metadata of a resource
6. TRACE: returns the original query the server received (e.g to compare, if the query was fiddled intermediately)
7. OPTIONS: returns a list of features the server supports
8. CONNECT: for ssl tunnel

The first two should be known very well. That is why I don't go into detail how a get or post request looks like. Apart from that Wiki does.

But reading the list carefully you certainly noticed that the leading four verbs map the CRUD (Create/ Read/ Update/ Delete) actions needed to proceed the full life circle an object is going through (maybe you knew before, but if so why the hell are you still reading this article?). Anyway, the Rails guys catched these four verbs to implement REST in RoR ('R' words are great!). So they had to reactivate PUT and DELETE, though we all know that the common browser don't know them (in situations like this I always remember the words of Bill Gates a browser was just a little snippet of code...)

... sorry for drifting away. The Rails community solved it by sending (posting) the verbs as parameters as I describe in the article "The very BEST of REST". A short answer as long as IE & Co. keep on being dumbly. To put it in a nutshell, a RESTful Rails application uses HTTP verbs "GET", "POST", "PUT" and "DELETE" to get, create, update and delete resources (objects) represented by the URI.

Believe it or not, that's all REST is about.

Now let's come to terms.

The pros:

• Clean URLs representing only the resource itself without any actions
• Different Responses of the same action are possible depending on the request (HTML, Ajax, XML).
• Less code through prevention of code repetitions (DRY) by using the same action for different requests (Multiclient).
• CRUD based Controller represent a specific kind of resource (simplifies and cleans up the structure of controllers).
• Clean Controllers are easier and enjoying to maintain

The contras:

• You have to get familiar with a new technique

Sounds like an easy decision to make. So make it and pimp your Rails application with REST.

I still didn't characterize how? True dat, mon!

Read The very BEST of REST!!