Why Should Your Controllers be RESTful ?
For most people that are non professionals and are starting with Rails, it’s most probable that they have never heard of or used REST before. I don’t want to go into too much theory, because you can find this anywhere online. Instead, i want to show you why it is important to use REST in your Rails programs and how this helps into making them more consistent.
Most new Rails programmers who are familiar with the model-view-controller design pattern, tend to think that controllers is just the way to connect your models with your views, by creating instance variables, flash messages and rendering or redirecting. While this is most of their job indeed, there is something more to it. A controller in a RESTful design represents an entity, a resource. For instance, a users_controller represents the actions that should be taken upon users. These actions are 4, as the CRUD acronym denotes. It is Create, Read, Update, Delete(CRUD).
CRUD in Rails
You have most probably already seen a fully restful controller if you generated a controller via the rails scaffold generator. You noticed that it has 7 actions. Notice that CRUD refers to 4 actions, so why does Rails have 7 predefined ones ? Well, let’s take a closer look on the image below (the image is taken from http://guides.rubyonrails.org/routing.html) :
This is the restful design for a photos controller. Notice that it’s a convention to have a singular model name like Photo and a plural name for the corresponding controller, like photos. The actions are pretty much self explanatory. Let’s associate them with the CRUD idea :
CREATE -> new, create
READ -> index, show
UPDATE -> edit, update
DELETE -> destroy
Why does create have two actions and not just one ? Well, when you want to create a new photo, you first need to complete a form that you GET from the web server and then submit the form back to the web server using a POST action. When you have a restful url like ‘/photos/new’, this one refers to the form that the user has to submit in order to create a new photo. When the user clicks on the form, the action that is taken is to CREATE the photo, thus inserting it to a database(or doing any other appropriate actions).
The READ action has two different actions, namely index and show. Simply, an index action is used to present a collection of photos, a list of them. A show action is used to present a single resource, that is a single photo information.
Finally, the UPDATE action uses the same idea as the one shown in the CREATE action, where edit is showing a form and UPDATE is submitting the form.
Fine, but WHY REST ?
REST works really well for two reasons. The first one is consistency among your controllers. If you are trying to keep your controllers limited to 7 actions, you are writing more localized and specific code. It’s like using a class properly. You do not want to have a class contain behavior that should be contained in another class, right ? It’s the same with RESTful controllers. Think of an example resource, say membership. For this one, you have a memberships_controller that manages new user membership actions. It rightfully has the seven REST actions, but then you realize that you now want to be able to create user membership groups.
You happily open up your memberships_controller and add the method ‘create_membership_group’. Seems reasonable right ? In fact, that would be a bad design idea. You see, a membership is a different resource than a membership group. The correct way to do it would be to create a new controller named ‘membership_groups’ and put a RESTful create action there. This way, your controllers have specific duty and never overextend themselves.
The second reason for using a RESTful Design is that, by convention, Rails is programmed around it. You already know that conventions are a very powerful idea in Rails. You probably like Rails because of that anyway. Rails is built to operate better with REST, using nested resources, generating named paths and so on. If you do program using REST, you will produce faster, better and more reliable Rails code, i can guarantee that.
So, next time you are in for extending your resources with new actions, stop and rethink ? Is it really a new action for that controller or an action for a new controller that you have to make ?