Designing RESTful Rails Applications

Recorded at:

Obie:

thanks for this interesting talk. There is definitely a lot of thinking behind it. If I understand the core of your argument, you are able to replace a typical action invoked from the controller by a combination of HTTP verb and a noun.

So instead of login/logout you create/delete a session resource, instead of reserving something you create a reservation resource, and so on...

The question I have is what do you gain in doing that. Unfortunately you mentioned in the talk that it was not part of your scope to talk about the implementation. If I try to imagine a new bid resource posted to an auction/bids I am wondering how different your implementation look like? aren't you mapping back from the resource representation to an action (say a stored procedure)?

Resources are "navigational" in nature, they are not "relational", in other words when a resource (representation) embeds a link to another resource, there is absolutely no way to "navigate" back from the target resource to the source resource, unless you also add a link there. This means in particular that if you truly transform an action into a physical resource creation, you would have to "search" these resources to understand the state in which the parent resource is (remember that when you are posting a session, you are not doing a PUT to the user to change its state to "logged in"). So to figure out if you, as a user are logged in, you would have to search the "sessions" for one that matches your profile. To know if something is reserved, you'll have to search the reservations and figure out if one matches to thing being reserved, and so on...

If on the other hand you are converting RESTful actions (HTTP verbs + nouns) into a store procedure call or a SQL statement, what have you gained?

I don't buy the "cacheability" argument because I don't know many enterprises that would "cache" the content of a bank account or an insurance policy. I don't buy the HATEOS benefit either, because as you very well know in MVC there is the annoying path where the model needs to update the view because something has changed in the back-end. Again in the enterprise things happen in the back-end. As a matter of fact, I was a bit surprised that in your talk you did not really mentioned HATEOS and that the "actions" seemed to be a bit "external" to the resource representations, which IMHO would be an anti-pattern for REST.

thanks,

JJ-