What exactly is REST architecture and how is it implemented in Rails?

Question

This is what I think of REST architecture.

For every resource, there is an unique URI.

We can manipulate that object using its URI and HTTP actions [POST, GET, PUT and DELETE]. The HTTP request transfers the representation of the state of that object.

In all the texts I have read, REST is explained in a weird and confusing manner.

One more thing, RESTFUL implementation in rails produces different urls for different purposes. Like /teams -> for 'index' method... /teams/new -> for 'new' method and so on. Ain't this moving away from rest, which defines that each resource has one unique URI???

Answer 1

As you might notice there are 4 HTTP actions but the basic CRUD operations in a typical web app require 7 different actions. Some of these don't actually do anything (like /new and :id/edit) and thus are sort of parallel to REST architecture. Also the index action does not act on the resource but rather on a collection of resource (thus also a unique url).

So the basic 4 HTTP actions map to a resource like this:

• GET maps to show -> get /teams/:id
• PUT maps to update -> put /teams/:id
• DELETE maps to destroy -> delete /teams/:id
• POST is a bit of an exception, since the resource is not yet existant thus it maps to the base /teams

So to summarize: each resource has its own unique url, plus rails defines a few additional urls for UI and collection purposes.

Answer 2

I'd start with chapter 5 of Roy Fielding's dissertation. There are a few basic principles:

• Resources: A resource could be typically something that you expose to the outside world as a part of your service. The emphasis is on identifying the resources (e.g: Book, UserList, CalculateDistance)
• URI: Give every resource an identifier (e.g: example.com/books/7654)
• Uniform interface: Use standard methods like GET, PUT. POST, DELETE, HEAD, OPTIONS
• Representations: A resource can have multiple representations. For example, a GET on a book can return a PDF of that book's content, a HTML of the content and for that matter even a GIF with the book cover and so on. A representation is essentially a collection of all the data and markup.
• Hypermedia: This one, in my opinion, is a very important principle. Implementation of this principle takes your application far ahead of the regular CRUD-like definitions the REST-style is boxed into. HATEOAS is the acronym which stands for Hypermedia as the engine of application state. When you click on a link or submit a form you are changing the state of the application, that's happening via hyperlinks (or hypermedia). There is very little coupling between a server and a client. A client navigates through the application via the links provided by the server. (there is a lot of discussion in the blogosphere on this priniciple ...) [Also look at Restfulie]

I have recently answered a question on good resources to learn REST, could be helpful.

I'm not familiar with Rails, so not addressing that part of the question.

Answer 3

Like /teams -> for 'index' method... /teams/new -> for 'new' method and so on. Ain't this moving away from rest, which defines that each resource has one unique URI???

No this is not moving away from REST, because as far as REST is concerned /teams and /teams/new are two different resources.

Answer 4

I think your understanding of REST is pretty good. It doesn't need to be any more complicated than it should be. Also @Surya outlines some very good points.

The way Rails maps the HTTP methods to controller methods is:

GET    => show
PUT    => update
POST   => create
DELETE => destroy

Two other resources/methods that rails provides namely:

resource/new  => new
resource/edit => edit

are most likely not resources for all practical purposes but are needed for building web pages and applications. If the client had full knowledge of the resource, these would not be needed. A client can just make POST and PUT calls with the resource information and create or update resources as needed. But since users are not expected to know the ins and outs of a resource, they need an easier interface to work with for creation or updation.

If all users were fully aware of the resources and were skillful enough with the command line, we wouldn't even need HTML. They can just curl in their interactions with those resources :)

index just makes it easier to work with collections. It is still a well defined resource and has a unique representation, for example /books. How it is handled on the server side code does not make it RESTless (I just made that up, but its awesome).