I know that if you listen to DHH and similar REST evangelists that
they would have you believe that all methods can be reduced to the
seven that fit the REST conventions (create, show, update, destroy,
index, new, and edit). I am not yet convinced.
For example can anybody think what model I would use for
forgot_password and reset_password. I have a user model that has a
password as a field. I do not really want to have a password model
since I guess this is supposed to map to a password table in the
database.
What does everybody think. As you can see this is more of a
philosophical than a technical question.
Looking forward to some interesting replies.
Would this not be an update to the user model? That is, changing a
password would be as simple as updating the user model.
However, lost password recovery is something else. From my
understanding, REST is not only a way to design web sites that are
then easier to use as an API, but to allow others to put their web
front-end on top of your RESTful database back-end. If this is the
case, wouldn't lost password recovery be something that the front-end
might do, given the basic primitives you provide?
To be honest, REST not something I am following closely, but I do
understand the need for a unique operation at a unique address. No
more index.php-does-everything for me
There's no reason to have a one-to-one correspondence between controllers and models, nor between models and database tables. I've used a separate AuthenticationsController (with new, create, and destroy actions) to handle logins. Works well.
Forgotten/reset password, depending on what you're doing, you might have a ForgottenPasswordNotificationController with new and create actions to send out notifications, and a separate PasswordsController (perhaps nested under your UsersController?) that has edit and update actions? Or perhaps PasswordsController#new posts to #create which in turn sends the notification? Just ideas here, and I haven't really thought through them too far, but it's a start. The thing to keep in mind is the resource that you're acting on.
Hope this helps. There's no reason you have to map everything to REST, but many times you can if you want.
In my experience, I've found that you either create a custom method
(blahblahblahdon'tdothatblahblah) or another controller. In this
situation, it would depend on the scale of the application and how
much the remote API was going to be used. Little to no remote API
usage? Custom method it is. A _lot_ of API usage...I might consider
another controller.
I don't think either way is the absolute correct way, but I think you
have to formulate your answer based on the application itself and how
it will be used.
Putting on my "Everything can be restfully modeled" hat, what about
this?
map.resources :forgotten_passwords
The new form would have a field for email address. Create would call
logic in User to do the reset. The link would be sent to the user,
using the reset code as the ID for forgotten_passwords
I know that if you listen to DHH and similar REST evangelists that
they would have you believe that all methods can be reduced to the
seven that fit the REST conventions (create, show, update, destroy,
index, new, and edit). I am not yet convinced.
For example can anybody think what model I would use for
forgot_password and reset_password. I have a user model that has a
password as a field. I do not really want to have a password model
since I guess this is supposed to map to a password table in the
database.
What does everybody think. As you can see this is more of a
philosophical than a technical question.
Looking forward to some interesting replies.
Anthony
I would create a PasswordRemindersController.
‘new’ action provides a form for the user to enter their username
and/or email, or something.
‘create’ action sends them an email with a reset password and
redirects to ‘show’ action.
‘show’ action simply gives a message that the email has been sent
and that they should check for it.
The ‘show’ action could be eliminated if you wanted the ‘create’ to
just show the message, but convention dictates that POST and PUTS
redirect on success, otherwise if someone started reloading that page,
it would keep resetting their password to something else and sending
another email.
As Michael pointed out, there is absolutely no need for a 1 to 1
correlation between controllers → models → tables. This is a
classic example of a RESTful controller with no need for a
corresponding model.
Thank you all for your replies. All very helpful and have got me to
reassess both MVC and REST again. I think that taken together there
will be some stuff I can implement, particularly not having to have a
model for every controller.
