Rails - Feb 2007 - Restful Rails Nested Routes Resource Name Consistency

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On 2/26/07, bradley.mazurek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<bradley.mazurek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> > 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Awesome.  That explains things well.

Thanks everyone.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---