Hi, I’ve read the blogs, I’ve seen the Peepcode screencast, and I even
read the beta book from the Pragmatic guys - still, I fail to understand
how REST can simplify my controllers beyond the CRUD operations.
Example: I got a simple article object. I got want to get the most
recent articles, that’s not supported by the CRUD stuff, so I add:
map.resources :articles, :collection => { :recent => :get }
… in my routes. Now say I want to flag some of those articles as
‘enabled/disabled’ or ‘featured/not featured’:
map.resources :articles, :member => { :featured => :put, :enabled =>
:put }
I can think of about 39303049 different ‘methods’ I need to call in this
fashion. Does it mean I have to add that many ‘custom’ resource routes
to my route file, just to then have to declare them as part of my
controllers? In which case, short if simplifying the CRUD action, REST
didn’t help simplify my controller at all?
I know I’m missing something, the question is, what 
If you guys
could point me in the right direction, that would be great…
On Nov 26, 2006, at 4:50 PM, Steve D. wrote:
… in my routes. Now say I want to flag some of those articles as
‘enabled/disabled’ or ‘featured/not featured’:
map.resources :articles, :member => { :featured => :put, :enabled =>
:put }
[snip]
Okay, first up is a disclaimer. I’m still getting my feet wet with
REST so this might be totally wrong. Proceed at your own risk.
When looking at your collection from these other perspectives (recent
= time, status = enabled/disabled/featured/etc), these other
perspectives become controllers.
GET example.com/recent
This returns some default timespan of recent articles.
GET example.com/recent/45
This returns articles from the past 45 days.
Or maybe you just take additional parameters in to your regular #show
method.
GET example.com/articles?begin=today&end=45
This might behave just like the #recent/45 example above.
I highly recommend looking at the articles on wikipedia [1] and
RestWiki [2] to understand how to apply REST principles. The REST
approach will likely result in more controllers, but each controller
will be much simpler to implement and test. If you are still stuck in
the mode that says there is a 1:1 relationship between controllers
and models then you might be in for a rough ride.
cr
[1] Representational state transfer - Wikipedia
[2] http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage
Thank you!
Can anyone confirm Chuck’s highlights? I get this feeling RESTful
application are still very much bleeding edge…
Steve D. wrote:
Thank you!
Can anyone confirm Chuck’s highlights? I get this feeling RESTful
application are still very much bleeding edge…
Like Chuck, I’m no REST expert, but am halfway through refactoring an
app to be RESTful, and it’s improving it no end. The structure is
stronger, the reasoning better, and the whole thing is a lot less messy.
In all my RESTful controllers I’m set up the :index action to display
the 20 most recent items, and if I need to filter it, perhaps by
restricting them to items that are tagged with “foo”, I simply pass a
:tag => “foo” parameter along with the request. It’s trivial if there’s
just one possible filter, not that much more difficult using case…when
with using more than one possible one. I’ve only needed to resort to
additional actions in a couple of controllers (and it’s a fairly big
app), and in those it’s been for specific destructive actions, e.g.
disapproving an item.
HTH
CT
On 11/26/06, Steve D. [email protected] wrote:
to my route file, just to then have to declare them as part of my
controllers? In which case, short if simplifying the CRUD action, REST
didn’t help simplify my controller at all?
Could you not just pass these “methods” during a post update? These
‘methods’ really sound like state information about the object that need
to
be updated. It sounds overkill and redundant to add specialized
methods
for performing simple state updates.
If you want to display or filter the displayed result by certain state
information you can pass them as parameters to either the index function
http://example.com/articles?enabled=true, etc. Alternatively if you wish
you
could create a custom :member function in the routes when you wish to
perform very selective filtering. Ie. recent 45 days of articles, etc.
Rest works well in some cases but possibly not in every case. If its
causing you more grief than its worth than don’t bother. I’ve started
developing a ‘rest’ app and I must admit that it does simplify my life
and
removes a lot of the redundant code/views.
Adam
Your collection methods are fine - think of collection actions as
alternative GET requests. This is still the R part of CRUD. You may
want to consider using query string parameters instead though.
For your update methods - these could all be part of a single update
operation.
On 11/27/06, Adam R. [email protected] wrote:
fashion. Does it mean I have to add that many ‘custom’ resource routes
to my route file, just to then have to declare them as part of my
controllers? In which case, short if simplifying the CRUD action, REST
didn’t help simplify my controller at all?
Could you not just pass these “methods” during a post update? These
‘methods’ really sound like state information about the object that need to
be updated. It sounds overkill and redundant to add specialized methods
for performing simple state updates.
Not only could he, but that’s what he SHOULD do. He’s simply updating
the attributes of a resource, which is what HTTP PUT is for.
Pat
If you guys