If someone asked me what was the best thing I had learnt over the last 12 months, I would say: REST.
I know that the RESTful approach requires changing our way of thinking, and it took me a while to "switch". The benefits are huge. From my experience the main advantages of REST are:
One of the examples that is hard/not worth (according to some people) to implement in a RESTful way is "Forgot your password" functionality. Some people feel like it could be just "/users/4/reset_password" and that we could use a custom action for the users controller. I know that it can work, but I see no reason to break the REST rules here (by adding a non-REST action to the controller).
My RESTful solution
The feature should let users provide an email, send them a link to a page, where they can change their password.
We have several steps to follow:
Given these steps, I split the code into the following controllers and actions:
Email Verification
We want to let people create a new Email Verification, so:
I created an EmailVerificationsController with new/create actions.
It is responsible for:
After veryfing the email, we want people to change (update) their Password, so:
PasswordController with edit/update actions
it's responsible for:
That's it.
Techniques
This example shows that a controller doesn't have to reflect a ActiveRecord class. There is no such model as EmailVerification in my code. It could be worth considering it, but in my case I don't think it was needed.
A useful technique for REST-izing your design is to turn verbs into nouns, thus making them easier to expose as resources. In this case, we wanted to verify an email, so I turned it into "creating an EmailVerification resource".
Sometimes changing the words slightly can help. Instead of resetting passwords, I use "update a Password".
As always, I try to move as much logic to the model as I can. Ideally I just call one model method and handle exceptions if there are any. See this article for more details about this approach.
A controller can use other models. In our case the PasswordsController could call User.update_attributes method to change the password.
Bonus
A friend of mine asked recently how I'd implement a feature, that let's an admin making another user a superuser.
My thinking here is that I turn the "making someone a superuser" into "creating a new superuser". This shows me that we now have a resource called Superuser. According to REST a Create action expects the params to be sent using POST. So we can just POST the id of the user to the Create action. In the Create action we just call admin.make_superuser(params[:id]).
Questions
What is your opinion about these solutions?
Would you solve them differently?
Feel free to ask me how I'd RESTfully implement other features.
I know that the RESTful approach requires changing our way of thinking, and it took me a while to "switch". The benefits are huge. From my experience the main advantages of REST are:
- the consistency it brings to the app,
- a standardized way of creating controllers,
- thinking always in terms of resources - what is the 'thing' that the user wants to create/update/destroy?
- a higher-lever abstraction that simplifies communication with other people in the team
- very often there's only one RESTful way of implementing a certain feature
- consistent API, in one project we use Flex for the UI, and being RESTful makes it very easy to work with Rails controllers.
One of the examples that is hard/not worth (according to some people) to implement in a RESTful way is "Forgot your password" functionality. Some people feel like it could be just "/users/4/reset_password" and that we could use a custom action for the users controller. I know that it can work, but I see no reason to break the REST rules here (by adding a non-REST action to the controller).
My RESTful solution
The feature should let users provide an email, send them a link to a page, where they can change their password.
We have several steps to follow:
- Show a page where people can type their email, verify the email
- Generate a reset_password code.
- Send an email with this link.
- Clicking on this link should check if it's a valid reset_password code
- If it is valid, then show a page where a user can type the new password twice.
- Display a message appropriate for the result (error when the passwords don't match etc.)
Given these steps, I split the code into the following controllers and actions:
Email Verification
We want to let people create a new Email Verification, so:
I created an EmailVerificationsController with new/create actions.
It is responsible for:
- finding the user by email,
- generating the reset_password code,
- sending the email,
- handling errors
After veryfing the email, we want people to change (update) their Password, so:
PasswordController with edit/update actions
it's responsible for:
- authenticating the user by the reset_password code,
- letting the user change the password,
- displaying errors.
That's it.
Techniques
This example shows that a controller doesn't have to reflect a ActiveRecord class. There is no such model as EmailVerification in my code. It could be worth considering it, but in my case I don't think it was needed.
A useful technique for REST-izing your design is to turn verbs into nouns, thus making them easier to expose as resources. In this case, we wanted to verify an email, so I turned it into "creating an EmailVerification resource".
Sometimes changing the words slightly can help. Instead of resetting passwords, I use "update a Password".
As always, I try to move as much logic to the model as I can. Ideally I just call one model method and handle exceptions if there are any. See this article for more details about this approach.
A controller can use other models. In our case the PasswordsController could call User.update_attributes method to change the password.
Bonus
A friend of mine asked recently how I'd implement a feature, that let's an admin making another user a superuser.
My thinking here is that I turn the "making someone a superuser" into "creating a new superuser". This shows me that we now have a resource called Superuser. According to REST a Create action expects the params to be sent using POST. So we can just POST the id of the user to the Create action. In the Create action we just call admin.make_superuser(params[:id]).
Questions
What is your opinion about these solutions?
Would you solve them differently?
Feel free to ask me how I'd RESTfully implement other features.
