[Catalyst] RFC: Catalyst::Controller::REST::DBIC

J. Shirley jshirley at gmail.com
Sun May 4 17:09:47 BST 2008


On Sun, May 4, 2008 at 9:02 AM, Christopher Laco <claco at chrislaco.com> wrote:
>
> Zbigniew Lukasiak wrote:
>
> > On Sun, May 4, 2008 at 3:54 PM, J. Shirley <jshirley at gmail.com> wrote:
> >
> > > On Sun, May 4, 2008 at 1:52 AM, Zbigniew Lukasiak <zzbbyy at gmail.com>
> wrote:
> > >  > On Sun, May 4, 2008 at 7:05 AM, J. Shirley <jshirley at gmail.com>
> wrote:
> > >
> > >
> > > >  >>  >  On a side note about REST - REST doesn't mean human readable
> URLs.  It
> > > >
> > >  >  >  means representative URLs.  The bit about cd/id/{CDID}/ smells
> like
> > >  >  >  named parameters going into positional parameters.  What is the
> real
> > >  >  >  difference between cd?id={CDID}&action=delete, aside from
> different
> > >  >  >  characters?  Where as with REST, /cd/{id} is a unique identifier
> for
> > >  >  >  that object and hence a full representation.
> > >  >
> > >  >  The problem I see with /cd/{id} is that when you have a primary key
> > >  >  that is 'create' - this would clash with the 'create' action.
> > >  >  /cd/id/{id} let's you separate the reserved words from the user
> data.
> > >  >
> > >  >
> > >
> > >  A pet peeve of mine is that people seem to have this weird idea that
> > >  primary key == id.  An id can just be some human readable mechanism to
> > >  looking up the item, where as the primary key is what is actually used
> > >  by the database to determine the relations.
> > >
> > >  They do not have to be the same field but often times they are out of
> > >  convenience.  In cases like this, they simply shouldn't be though.
> > >
> >
> > Sorry but I don't understand your point - so maybe first I'll restate
> > mine.  If you have primary key in the database that is of type varchar
> > (or char or ...) then 'create' is a legitimage value for that primary
> > key.
> >
> > If you just don't like the string 'id' in the URI - then I have not
> > any preference to that - it can be /foo/primary_key/ for me.
> >
>
>
>  My pet peeve is that /foo/primary_key makes computers happy... but not
> people.
>
>
>  /products/23
>  /products/ABC-1234
>
>
>  The first is the PK for a product record..
>  The second is the actual sku for a product... just a unique as the pk...but
> not the PK itself...
>
>
>  Now what does "id" mean in this case?
>  What id your SKU is a numeric just like your PK?
>
>  Two different and equally useful ways to get at the same resource.
>
>  If you're talking about an interface where humans know the skus, and
> computers know the id (restfully and/or remotely).. you need a sane uri:
>
>  /products/id/<id>
>  /products/sku/<sku>
>
>  In the end, I always run into a situation where humans (think marketing SEO
> pushers who know not of REST) want something other than a true restful uri.
>
>  -=Chris
>
>
>

To be honest, I'd rather see something like /products/-{id} and
/products/{sku}.  Simple checks like that make things easy, and the
'-' is inconvenient for a human but then they don't have to type a
(seemingly redundant) /sku at each time.

But also, with an index, a sku lookup should be equal to an id lookup,
so in this particular hypothetical case I would always go with the
sku.  If you use DBIC or any other sufficiently sane ORM, you don't
need to ever bother directly with the primary key field, and just do
$obj->relation and be done.



More information about the Catalyst mailing list