REST, API - confusion

[eluser]tinawina[/eluser]
Yes - I see your points. And yes I am overthinking it. I tend to do that, it's a fatal flaw -- or my charm, take your pick.

I've been thinking (uh oh) about this more, and trying to apply K.I.S.S. to this effort. I think these URLs would work fine for us where users are concerned:

www.oursite.org/users/screen_name (displays this user's profile info)
www.oursite.org/users/allUsers (displays a list of all active users)
www.oursite.org/users/screen_name/updatePassword (user can get to update screens when logged in)
www.oursite.org/users/screen_name/updateProfile
www.oursite.org/users/screen_name/updateEmail

We also have research contributors who need to create a different kind of account (tied up with copyright on research). Much of what they need to do overlaps with processes used in the User account creation and maintenance routines. Can I ask -- is handling all of my User stuff in one controller the right way to go? Or should I expand User to include Contributors too since they share processes with the difference being only in table names and a few field names?

Say I have a controller called Users with these methods:

- createUser (wh would include validation and callbacks for unique data)
- updateProfile
- updatePassword (same here with validation and callbacks)
- updateEmail (and here...)
- deleteUser (admins only)
- displayUser
- displayAllUsers

I'm thinking this is the way to go since I'd only have to deal with password and email callback code needed in the createUser, updatePassword and updateEmail methods once in this one controller. And this puts my user stuff in one place (with required model and view calls).

Unfortunately I have a need for the password callback when I let a user reset their password via the password-finder tool. I'm really trying to avoid duplicate code! But all things related to login are in my Login controller in an attempt to be organized.

I could also use the callback code for email and password check (as well as username check) for research contributors. But my research contributors do a lot of other things that Users don't -- like add and maintain research listings.

How would you handle this? Would you sacrifice duplicate code for clear controller organization?