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

[Zbigniew Lukasiak]

On Sun, May 4, 2008 at 6:06 PM, J. Shirley <jshirley at gmail.com> wrote:
> On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>  >
>
> >  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 point is that you do not have to use the primary key as the record
>  lookup identifier.
>
>  A user has no control over the record lookup identifier (ID) when you
>  do things like /user/{primary_key} (or /user/id/{primary_key}, which
>  is just converting named params to positional in a weird way).  In a
>  lot of cases, the record lookup identifier makes more sense to be
>  somewhat bound to the user.  As an example, lets say registering for a
>  web service where you have to have a unique login:
>     POST /user/jshirley
>     ---
>     login: jshirley
>     first_name: Jay
>     last_name: Shirley
>     ...
>
>  Now, it's a simple check here - does /user/jshirley exist?  If so,
>  reject the request appropriately.  If not, create the user at
>  /user/jshirley.
>
>  The primary key that the database uses is completely useless to the
>  user.  /user/1634254 is silly, /user/jshirley is meaningful.
>
>  If the ID is generated, that gets a bit trickier but I usually handle
>  that with a POST to /user with the data and then let the application
>  forward me to the final URL of where the resource exists.
>
>  The other reason is that this system breaks when you no longer have
>  records tied to a database.  As an example, if you use an md5 sum of a
>  file as the identifier.  /file/1234 doesn't work because it isn't in a
>  database under that system (think of a MogileFS cluster or something
>  with hash keys rather than primary keys in the conventional sense) -
>  instead /file/{md5sum} is used.
>
>  In brief summary, over-utilization of primary keys as record lookup
>  identifiers ends up diminishing the human readability and
>  accessibility of your web service.   I'm not trying to win over any
>  converts, because I think there is a time and a place for each (even
>  in the same application, it just depends upon what each action is
>  really doing).  If I'm not building something that is REST/webservice
>  driven I tend to do the /user/{id or token} (with a simple regex to
>  check, and if someone has a login of all numbers then screw 'em) - but
>  it's a very different strategy when I work with webservices -- each
>  time I always make sure if the record lookup indicator should be the
>  primary key, and what cases should it not and then react accordingly.

Then we are talking about two diffrent things.  My point is that you
should not have /foo/create and foo/{id or token} - because you mix a
reserverd work 'create' with data, you can never guarantee that the
data, be it primary key or token or whatever, does not contain
'create'.

I do understand that in full REST design you would not have a
'/foo/create/' uri - but if you want to add this REST as an add-on to
a controller you'll still have other methods on the controller that
could conflict with the token/id.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/