Re: Hatred towards Nested Polymorphic Paths

Geoff B
2007-07-09T18:11:31Z

1) the uri

/albums/79/tracks/219

doesn''t reveal whether the underlying association between Album and
Track is has-many, has-and-belongs-to-many, or has-and-belongs-to-many-
through. I see this as an asset -- you can refactor your model
associations as business requirements change without having to rework
your uri structure.

2) even if you do have a join table -- say Book
has_many :authors, :through => :authorships -- you still might want
the uri to reference a Book and an Author, which are concrete objects.
rather than an Authorship, which is an abstract concept. In the real-
world DSL of the book trade, a customer might request more information
about a book''s author, or about a particular book written by an
author, but not for more information about an "authorship."


On Jul 8, 9:01 pm, "Evan Weaver" <ewea...@gmail.com>
wrote:
> Agree. some_model/1/other_model/2 is a lame way to refer to join_model/1.
>
> Evan
>
> On 7/7/07, Josh Peek <joshp...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 7, 11:12 am, Geoff B <gbues...@gmail.com> wrote:
> > > I think a case can be made for using an [@album, @track] nested
route
> > > -- say a user browsed to album 45, and then clicked track 219 --
if
> > > your UI requires a "back to album 45" navigational link
on the track
> > > page, you couldn''t infer the referring album id from the
resource id
> > > alone if there''s a many-to-many relationship between
albums and tracks
> > > -- instead, you''d need to grab the album id from the URI
>
> > If your referring to a HABTM relationship, look into creating a real
> > join model between them using has many though. That why you have a
> > real resource you can point your url to.
>
> --
> Evan Weaver
> Cloudburst, LLC