I love REST, but I dont practice it like religion.
Developing an application using nothing but seven controller actions
will quickly defeat the purpose of a clean API.
The question here is: What do you do with operations that doesn’t
neatly fit into basic CRUD?
- Put it into one of the seven default REST actions anyway, and use a
bunch of if-tests to make one action handle two types of requests?
- Define a new RESTful action on the existing resource using the
collection/member parameter in the resource mapping?
- Define a new resource?
- Make an unRESTful action, either in a new or existing controller?
All 4 options has it’s uses. Which one works best depends on the
A couple of principles that helps me decide:
I want one controller action to only do one thing, or more specific:
have one concern.
I dont define a new resource, or add a custom RESTful action unless
the resulting API makes logical sense.
Reports are a good example of something that often doesn’t fit well
into a RESTful style. Finding good short names for the actions become
hard, and hence the resulting routes becomes cumbersome.
What I usually do is to have an unRESTful reports controller.
Graphs are a kind of report so it could be best for you to make these
actions unrestful, but it’s not really possible for me to say without
knowing what the actual code looks like.
Think about each of the options you have and try to figure out which
solution would be cleanest. REST is all about a clean API, but the
code behind it should also be maintainable. That’s why using nothing
but seven controller actions rarely works well in practice.
On Apr 27, 7:55 am, Fearless F. [email protected] wrote:
Also, the app calls for radically different page layouts depending on
selected display style (e.g. plot vs table view) – can one controller
invoke multiple views? Or must you create one controller per view?
You can use "render :template => " to control which template a
controller action renders.
This allows you to use if-tests if you need one action to render
different views depending on something.
Another option is to have one view that renders different partials
depending on something.
And finally, would you back the controller with a Plot model? Except
for caching complex plots, I don’t see a real motivation for db
persistence, unless, of course, the Rails framework really wants a Plot
model to go with a Plot controller.
Whether or not you need a new model has nothing to do with REST.
If you are going to work with an object that doesn’t have a model
already, then a new model would help you put the code in the right
A model does not need to be DB-backed.