Luke Redpath makes a valiant attempt to DRY up RESTful Rails controllers as he writes Refactoring REST: searching for an abstraction. I can see how this can be very useful if your controller methods follow the simple paths. Good to see some implementation patterns emerge that build on the assumptions that your controller is RESTful.
I sent a helpful PDF on Rails support for CRUD and REST to a buddy of mine. He asked for some clarifications. Here’s what I sent to him.
Try to think in nouns, and not verbs. Nouns are your Model classes, things which you can have instances of (User, BankAccount, Book, Login). That last example, Login, is where (hopefully) the light bulb goes off. Consider if you could only Create, Read, Update, or Delete *things* (nouns). How would you do a login?
One way, the old way, is to add a login method on your user controller. Think about what you’re saying. You want to call the method (or *verb*) “login” on User. Already you can see we’ve left the CRUD methods, and a warning bell should go off.
If a user authenticated via User.login, what artifacts are generated? Are you simply returning a boolean? If so, how do you track logins? How do you ask “When was the last time I logged in?”
To solve the problem, you noun-ify the concept of login. Create a Login model, and make a relationship between User and Login.
User has_many :logins
This way, you can Create an instance of Login. No more special verb for login, just Create one. This way, you’re tracking all logins as *things* (nouns) and you can do CRUD on them all you want.
The moral of the story is: Think in *things*, not actions. Nouns instead of verbs. Use relationships like `has_many`, `has_many :through`, and `belongs_to` to connect the dots. Then, you are free to have very simple Controllers which are only concerned with CRUD methods.
Once you get these core concepts down (which are just standard Web app best practices), you can investigate Rails’ REST support. It’s a bunch of conventions to help build CRUD apps.
Restful Routes talks about the new RESTful programming models that are now possible in Rails (now in Edge, soon to be in the released version).
In this case, the url /comments/1;approve would be created. The rationale is to use the path to the left of the semicolon for a resource’s identity, and to use the path to the right of the semicolon as a modifier. Frequently this modifier would be an operation that you would perform on the resource, such as approving a comment that requires moderation.
This isn’t very restful. This modifier hack is just another way to force another verb into the mix.
The best way to be more RESTful would be to PUT a representation of the comment with the approval flag set to true. In REST, representations of resources are exchanged. Instead of referencing the URI of the comment, with a verb modifier stuck on the end, send along a representation of the whole comment.
Now, you’re saying, “But how do I do that in Rails?” This is, of course, very difficult. Most of the fault lies with the XHTML spec, which has been updated to support full method selection in form actions, or the inability to send form data as XML. You don’t really care about the representation format, so the current name=value pairs would work OK as the body of the PUT. But a lack of PUT as a form action? It’s a RESTful crime.
Another way to be more RESTful would be to create a new resource, a collection that accepts ApproveComment documents. This is a document style web service, but minus the SOAP. This models the event that is “Approve this Comment”. You can then POST this new even to the /comments/approval_queue. The representation would include the comment id you want to approve.
This intermediary resource is similar to why Rails has introduced :has_many :through. Those old many to many join tables are old and busted, and first class join models are the new hotness. They function to enrich the domain model and make relationships themselves a first class citizen. I think of these new documents, the ApproveComment document, as filling in the same type of gap.
The URI, /comments/1;approve, both identifies the noun and the verb. To me, that violates a central tenent of REST, in that you should only need the CRUD methods. I see no difference between /comments/approve/1 and /comments/1;approve when talking about the intended consequences of the user’s request.
It’s great to see Rails try to be more RESTful, don’t get me wrong. They are doing some great work here. I’d like to see them take it even farther, and use only the HTTP verbs (GET, POST, PUT, DELETE) and make new documents (representations) for what would have been that URI modifier.
Resources on Rails highlights some of the new exciting changes to appear in Rails 1.2. The most exciting is ActiveResource, which CRUDifies models as HTTP resources. Go REST!
On how Rails is seeing the true light with CRUD, REST, and HTTP.