Can all methods be made to fit REST?

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

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 :slight_smile:

–Michael

On Oct 18, 2007, at 12:29 , Ant wrote:

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.

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.

Michael G.
grzm seespotcode net

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.

–Jeremy

On 10/18/07, Ant [email protected] wrote:

database.


http://www.jeremymcanally.com/

My books:
Ruby in Practice

My free Ruby e-book

My blogs:

http://www.rubyinpractice.com/

Ant wrote:

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.

On Oct 18, 12:29 pm, Ant [email protected] wrote:

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.

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

http://app.com/forgotten_passwords/123456asswqdwqj1221312321

The show on the forgotten password would have a form to put to the
user resource and change the pass.

Actually, now that I say all that, it doesn’t seem nearly as crazy as
I thought it would. That’s pretty clean.

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.

Thanks again,

Anthony