In this presentation from QCon SF 2007, Obie Fernandez explains REST and gives practical tips on how to use Rails' REST features to write RESTful applications.
Obie Fernandez is the CTO/Founder of HashRocket, a boutique web consultancy and product shop headquartered in Jacksonville Beach, Florida. He has a blog http://obiefernandez.com/ and speaks at conferences and technical user groups on a regular basis. He is a series editor and book author for Addison-Wesley.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Re: Problems ....
Re: Problems ....
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.