In my Rails app I have a fairly standard has_many relationship between two entities. A Foo has zero or more Bars; a Bar belongs to exactly one Foo. Both Foo and Bar are identified by a single integer ID value. These values are unique across all of their respective instances.

Bar is existence dependent on Foo: it makes no sense to have a Bar without a Foo.

There's two ways to RESTfully references instances of these classes. Given a Foo.id of "100" and a Bar.id of "200":

1. Reference each Foo and Bar through their own "top-level" URL routes, like so:

   • /foo/100
   • /bar/200

2. Reference Bar as a nested resource through its instance of Foo:

   • /foo/100
   • /foo/100/bar/200

I like the nested routes in #2 as it more closely represents the actual dependency relationship between the entities. However, it does seem to involve a lot of extra work for very little gain. Assuming that I know about a particular Bar, I don't need to be told about a particular Foo; I can derive that from the Bar itself. In fact, I probably should be validating the routed Foo everywhere I go (so that you couldn't do /foo/150/bar/200, assuming Bar 200 is not assigned to Foo 150). Ultimately, I don't see what this brings me.

So, are there any other arguments for or against these two routing schemes?