Rory McKinley wrote:
I am trying to use RESTful design practices, but I have areas of the design which seem to suggest that I should have more than one level of nesting. Now, all of the reading I have done, tells me that this is a very bad idea, so I was wondering if the esteemed memebers of the list can help me out.
There are many goals.
Each goal has many milestones.
Each milestone belongs to one user.
The UI is going to make fairly heavy use of AJAX to update elements, and that will lead to situations where I need to get the following:
All Milestones for a particular user and a particular goal.
Now, if I go crazy with the nesting, I would end up with this as a url:
Can anyone suggest RESTful alternatives, that won't violate the best practice of only one level of nesting?
Thanks in Advance
No matter how you setup your routes, the milestones controller is going to be the entry point, and it's going to need a :user_id and :goal_id in params (unless you're going to also allow just one or the other). You're only RESTfulish route options that I can think of are...
If the typical use of this application would be users looking at their own milestones, then opt 2 is probably what I would go with. Then users/#/milestones could be a list of *all* of that user's milestones, and they could then choose a 'goal' to *filter* the list. That also opens the door for option 1, so that someone could see all of the milestones for a goal, and filter them by user.
What I think it boils down to is which seems to make the most sense based on how the data will be visualized. I've occasionally used deeply nested routes for certain actions, but only in cases where it really made sense (at least to me) to do so. All of the above 4 options are technically legal, so... it's really just a matter of preference.
Note however that I used the *plural* versions of 'user' and 'goal' in my sample routes. Using plural names in your routes and controllers is (to the best of my knowledge) standard and recommended convention.