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

[J. Shirley]

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.