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

[Christopher Laco]

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