Comparing Two Models of Composing Actions

I've been working with authentication systems lately and I'm basically seeing actions composed in two different ways.

_Model A_

In Model A, a form posts back to the action that rendered it, and if the form post is successful then the action redirects elsewhere. For example, account creation in Acts As Authenticated is like this:

  View Action: account/signup   View: views/account/signup.rhtml   HTML Form Action: account/signup   Psuedo Controller Code:

  def signup     if not form post       render template     else       create new user       if success         redirect somewhere       else         re-render template with error message       end     end   end

As you can see, this action is very similar to what a Controller#new/ Controller#create pair typically do, however the overall composition is using more of a "post back" technique.

Additionally, other methods in AAA--login, change_password, etc.-- follow this model as well.

_Model B_

In Model B, the flow of things is more RESTful.

  View Action: users/new   View: views/users/new.rhtml   HTML Form Action: users/create   Psuedo Controller Code:

  def create     create new user     if success       redirect somewhere     else       re-render action with error message     end   end

As you see, is the more traditional Controller#new/Controller#create pair model. In my view, this is the evolving best practice because it's more RESTful.

All that said, a few questions as I'm trying to get my head around authentication, but the thoughts are broadly applicable:

1) In authentication systems such as AAA, there is both an Account and User controller. But, there is no account model--both the User Controller and Account Controller act upon the User Model. This is what I am trying to get my head around: what is the philosophy or theory behind having two Controllers?

In Account, the actions are typically formulated using Model A whereas in User the actions are formulated using Model B. Again, why?

2) Where do actions like login, logout, forgot_password, change_password belong. Those would seemingly be actions that "act on" a User, but they're not RESTful (i.e. C, R, U or D). Perhaps this is why there is an Account Controller--it contains User actions that are not RESTful.

3) If the last sentence of #2 is true, then why does Account#signup exist? It seems to be a duplicate of the User#new/User#create pair (i.e. the C in CRUD). (In fact, this is what got me thinking about this whole topic: why does AAA implement both Account#signup and User#new/User#create?)

Bottom line: I'm trying to get my head around the role of the Account Controller, and the relationship between the Account Controller and User Controller. Underlying that question is a) I can't make up my mind if I should have both Account and User, or just User, b) if I have both, then which actions belong in each, and c) which composition model from above is the appropriate best practice.

I hope I've expressed all that clearly...thoughts??


I'd argue that the second method was LESS restful.

Rest is not about having actions named create read update and delete, it's about using the http methods post, get, update, and delete to act on resources represented by uris.

Ya know what, you're exactly is less RESTful. A few semi- disconnected questions:

1) My original confusion still stands, though: what is the purpose of the Accounts controller? Should I be using Accounts#signup or Users#new?

2) If we're being truly RESTful then then answer is Users: if you POST to /users then we're calling Users#new. (I guess that's not a question.)

3) With that in mind, where do actions such as #login, #logout belong? I'd say they belong on User and that the Accounts controller is a complication, but I'm not sure. Also, where do these types of actions fit in with REST?