Restful Rails Nested Routes Resource Name Consistency

Rails
1

Hi,

Nested Routes often have what seems to be extra information, and I’m
not certain why.

I can understand why “GET /projects/1/iterations” needs to have a
project id. However, why does “GET /projects/1/iterations/1234” need
to have the project id? It seems like “GET /projects/5678/iterations/
1234” would accomplish exactly the same thing unless the controller
explicitly checked for the fact that iteration 1234 doesn’t have
project 5678 as it’s parent.

I assume this is done for resource identification consistency.
Because the URL represents a resource, the resource should be
consistently named, even though some of the information isn’t needed.
Is this the case?

But that begs the question: do the two URLs refer to the same
resource? Logically it seems they shouldn’t. But from my
understanding of the internals, it looks like from the controllers
perspective they would be: both would refer to iteration 1234. What
am I not understanding? Are there automatic consistency checks?

Thanks,
Brad

2

Because the URL represents a resource, the resource should be
consistently named, even though some of the information isn’t needed.
Is this the case?

If it is indeed a nested resource, all of that information is needed.

But that begs the question: do the two URLs refer to the same
resource?

/projects/1/iterations/1234 ---- refers to iteration number 1234 OF
project 1. There could also be iteration 1234 OF project number 2. /
projects/5678/iterations/1234 — refers to iteration number 1234 OF
project 5678. How can you find this gmail post without first knowing
which gmail group it belongs to?

3

If it is indeed a nested resource, all of that information is needed.

Isn’t iteration id sufficient?

/projects/1/iterations/1234 ---- refers to iteration number 1234 OF
project 1. There could also be iteration 1234 OF project number 2. /
projects/5678/iterations/1234 — refers to iteration number 1234 OF
project 5678.

How can there be two records in the iteration table with id 1234?

Or does using nested routes somehow strongly couple the two classes in
the model (GACK!) so that composite keys are used for the iteration?

How can you find this gmail post without first knowing
which gmail group it belongs to?

If thread ids have a common unique name space (as database keys are),
then I don’t need to know the gmail group. I just need to know the
message id. Or what am I missing?

Thanks,
Brad

4

The fact that nested resources require both ids is excellent for cases
where the second resource uses a different database. In the app I’m
currently developing, each site uses its own db. So these two urls

http://domain.com/sites/1/entries/2
http://domain.com/sites/2/entries/2

do not map to the same resource at all. Without the site’s id being
part
of the url, I’d be at a loss to find out which site to use. I’m pretty
sure
this is intentional on the part of the Rails developers even if the
normal
usage is one shared database for all models.

RSL

5

The fact that nested resources require both ids is excellent for cases
where the second resource uses a different database. In the app I’m
currently developing, each site uses its own db.

Ah, that’s an interesting use case! Yeah, in that circumstance, I can
see how that would be completely understandable, as they would both
refer to unique db records.

But, that would seem to be an atypical usage. In the case where all
records are in the same database, does anyone know what the expected
behaviour is?

Brad

6

Awesome. That explains things well.

Thanks everyone.

7

I can understand why “GET /projects/1/iterations” needs to have a
project id. However, why does “GET /projects/1/iterations/1234” need
to have the project id? It seems like “GET /projects/5678/iterations/
1234” would accomplish exactly the same thing unless the controller
explicitly checked for the fact that iteration 1234 doesn’t have
project 5678 as it’s parent.

If you’re only referring to the :id of your iterations table, then
you’re correct that there’s no difference, and there really isn’t any
reason to use a nested resource, except it still makes for a more
logical url when you can see what project your iteration belongs to.
However, a many:many relationship dictates that you need both ids,
such as:

/projects/1/member/52
/projects/2/member/52

Also, you can use other attributes from your nested model, such as:

/book/1/page/1

Where the lookup for page isn’t by some meaningless :id, but
by :position (i.e. sequence). This way you can request the first page
of the book just by going to …/page/1.

I assume this is done for resource identification consistency.
Because the URL represents a resource, the resource should be
consistently named, even though some of the information isn’t needed.
Is this the case?

If your iterations model is a first-class independent model that you
only need refer to by its own id, then I don’t see an absolute reason
for nesting it, except for logical urls.

But that begs the question: do the two URLs refer to the same
resource? Logically it seems they shouldn’t. But from my
understanding of the internals, it looks like from the controllers
perspective they would be: both would refer to iteration 1234. What
am I not understanding? Are there automatic consistency checks?

I don’t think there is any consistency checking in a one:many
(has_many/belongs_to), but you’re provided with both params so you can
sanity-check or customize your own lookup however you choose.