Couple questions, mainly around RESTful resourcing

Let's say we have users, posts, and comments.

I figured that in order to show a list of posts from a user, I'd have to nest it.

All good, I figured it out without too much trouble, but then after a while I started to get confused. Where would I place comments if I want it to be nested under posts? Nest it 2 levels down? I hear it's best to keep it only one level, so I'm not sure the best route to take for this type of setup.

If anyone could give some feedback on that, I'd really appreciate it.

Next, how would I take care of the 'admin' side of things RESTfully?

1) How could I specify a user to be an admin, "virtually" (without a field in the database) I saw something like this in the environment.rb from Railsconf

2) Should there be a completely different admin "abstract" controller? That doesn't make much "DRYness" sense to me, so I think I could use the same controllers as any other, but restrict the actions to only an admin with a before filter or something?

So if anyone could give some feedback on these two RESTful problems, I'd really appreciate it.


p.s: if anyone knows RSpec pretty well, could you help me understand why my posts_spec is blowing up with this restful routes stuff? :slight_smile:

Thanks again!

I think you need to stub User.find too


I've tried that and no luck.

Anyone have a response to the other things?

Good questions... I'll take a shot.

Regarding user/posts/comments, I personally don't think it's a problem to nest two levels deep in this case; however, it's easy to forget that you can provide multiple routes to your resources, and that can avoid the two-deep scenario:

map.resources :users do |user|   user.resources :posts end

map.resources :posts do |post| post.resources :comments end

So then:

/users/34/posts # => all the posts for user #34

Now that you can get a list of the post ids for that user, you can plug those into:


Hopefully you can see where I'm going... I'm just saying, you don't have to nest if you don't want to, and usually you can avoid it.

Regarding the Admin stuff, usually just going with a before filter works great. Set instance variables as needed so the view can know what it needs to display.