Restful Rails Nested Routes Resource Name Consistency

rubyonrails-talk
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

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.

7

Awesome. That explains things well.

Thanks everyone.