I’m in the process of converting a project to be RESTful (Rails 1.2.1) but am running into an issue I can’t quite solve (gracefully).
I have a list of Accounts that all need to be modified in the same way (‘paused’) Using the restful routes, I can easily setup a route for pausing one:
I can’t figure out how to force the named route to use the PUT method, plus I have to hack my ‘pause’ action to accept both a single Account id (params[:id]) as well as multiple ids. I’m sure I’m missing something simple. I can’t seem to find much helpful documentation or examples.
I’m in the process of converting a project to be RESTful (Rails 1.2.1) but am running into an issue I can’t quite solve (gracefully).
I have a list of Accounts that all need to be modified in the same way (‘paused’) Using the restful routes, I can easily setup a route for pausing one:
I can’t figure out how to force the named route to use the PUT method, plus I have to hack my ‘pause’ action to accept both a single Account id (params[:id]) as well as multiple ids. I’m sure I’m missing something simple. I can’t seem to find much helpful documentation or examples.
Anyone?
Ed, reading your requirement leads me to think that you are missing a Model.
The Accounts likely are connected in your domain a belongs_to relationship.
Yes, the Accounts belong to User. Although, in this situation, I’m working on an admin interface. There is a screen of Accounts and the admin has the ability to manage them all in bulk.
Although I don’t know more, having such a requirement would be an indication to me that I’ve not modeled something important.
And having such a relationship would allow you to track the transactional info that happens through such a group REST action.
I’m not sure I follow you. Elaborate?
I’m running into many obstacles when changing my actions to work in the RESTful environment. Mostly things that aren’t standard CRUD actions. I wish there was more documentation on the new routing and resource features!
The idea I was getting at that you likely haven’t modeled, we’ll call that relationship “Transaction”.
So:
Users belong_to Account
Account has_many Transactions
but also Account has_many Transactions, and likely Users
(I likely am not talking the right language for your domain, but you should be able to make the translation. You may even need an AccountTransaction has_many to make this work).
So when changes are made to an account, you make it through a Transaction model (and REST) If you have different types of bulk Transactions, then you may need to pass a Transaction type.
so doing a REST on the Transaction model will act on all the Accounts for that User - and when you record the Account changes, you can track date/time and other items that can be used for auditing.
Generally REST really works when your data Model is rich (IMO), or said another way, you can test your data model through a REST implementation. Watching DHH’s presentation on his first thoughts on implementing REST you’ll see him run into a wall, and then realize he was missing a Model.
If you would like more info on refactoring to REST, check out this
article by Scotty Raymond (IconBuffet, Blinksale, etc). It is
available on his site, but I have found this link to be more reliable
(doh!):
One of the things to note is how REST takes a different way of thinking
about your app. Where before you may have had a login action on some
account controller, now you might want an object to represent what a
login does. A login creates a session, so why not have a RESTful
sessions controller? That is what Scotty has done here. Most of the
time, if you are struggling with custom actions, it is because there is
some other way to represent the relationship than what you had before.
Just think in terms of "what am I creating here?"
