Re: RFC: Catalyst::Controller::REST::DBIC

7 msg	Configuration of $c->log with Catalyst::Log:...
8 msg	Invalid session ids being generated
4 msg	Catalyst / dbix-class / mysql / REST job
2 msg	Strange UTF16 warning
1 msg	Wikipedia article improvement?
5 msg	FastCGI: incomplete headers (0 bytes) received ...
5 msg	Basic CRUD Tutorial
2 msg	How to display a single HTML::Widget form field...
7 msg	Let's port Twitter to Perl
8 msg	Catalyst, utf8 in form element type text
17 msg	Anybody who fancies some LWP poking ...

RFC: Catalyst::Controller::REST::DBIC
\ luke saunders (4 May 2008)
. \ Patrick Donelan (4 May 2008)
. . \ J. Shirley (4 May 2008)
. . . \ Zbigniew Lukasiak (4 May 2008)
. . . . \ J. Shirley (4 May 2008)
. . . . . \ Zbigniew Lukasiak (4 May 2008)
. . . . . . \ Christopher Laco (4 May 2008)
. . . . . . . \ J. Shirley (4 May 2008)
. . . . . . . \ Steve Atkins (4 May 2008)
. . . . . . . . \ Christopher Laco (4 May 2008)
. . . . . . . . \ Matt S Trout (5 May 2008)
. . . . . . \ J. Shirley (4 May 2008)
. . . . . . . \ Zbigniew Lukasiak (4 May 2008)
. . . . . . . \ Matt S Trout (5 May 2008)
. . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . \ Andrew Rodland (5 May 2008)
. . . . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . . . \ Zbigniew Lukasiak (5 May 2008)
. . . . . . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . . . \ luke saunders (5 May 2008)
. . . . . . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . . . . . \ Peter Karman (5 May 2008)
. . . . . . . . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . . . . . . \ luke saunders (5 May 2008)
. . . . . . . . . . . . . . . \ Peter Karman (6 May 2008)
. . . . . . . . . . . . . \ luke saunders (5 May 2008)
. . . . . . . . . . . . . . \ J. Shirley (5 May 2008)
. . . . . . . . . . . . . . . \ Peter Karman (5 May 2008)
. . . . . . . . . . . . . . . \ luke saunders (5 May 2008)
. . . . . . . . . . . . . . . . \ Ashley (5 May 2008)
. . . . . . . . . . . . . . . . \ Zbigniew Lukasiak (6 May 2008)
. . . . . . . . . \ Matt S Trout (5 May 2008)
. . . . . . . . . . \ J. Shirley (5 May 2008)
. . . \ luke saunders (4 May 2008)
. \ Aristotle Pagaltzis (4 May 2008)
. . \ Matt S Trout (4 May 2008)
. . . \ J. Shirley (4 May 2008)
. . . \ Patrick Donelan (5 May 2008)
. . . . \ luke saunders (5 May 2008)
. . . . . \ Matt S Trout (5 May 2008)
. . . . . . \ Patrick Donelan (6 May 2008)
. . . \ Aristotle Pagaltzis (5 May 2008)
. \ Zbigniew Lukasiak (4 May 2008)
. . \ luke saunders (4 May 2008)
. . . \ Zbigniew Lukasiak (4 May 2008)
. . . . \ luke saunders (4 May 2008)
. . . . . \ Zbigniew Lukasiak (4 May 2008)
. . . . . . \ luke saunders (4 May 2008)
. \ Jonathan Rockway (4 May 2008)
. . \ luke saunders (4 May 2008)
. \ Zbigniew Lukasiak (15 May 2008)
. . \ Mark Trostler (15 May 2008)
. . . \ Zbigniew Lukasiak (15 May 2008)
. . . . \ Aristotle Pagaltzis (15 May 2008)

1 msg	Kill the book thread please
2 msg	More Catalyst Template Toolkit examples?
6 msg	Fw: high school reunion (no subject)
2 msg	(no subject)
6 msg	Using URIs for my app in another program
4 msg	Tutorial
11 msg	$row->copy causing exit from controller(!)
14 msg	How to print/display some data in an end action

Subject:	Re: RFC: Catalyst::Controller::REST::DBIC
Group:	Catalyst
From:	J. Shirley
Date:	4 May 2008

On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak <zzbbyy> 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.

_______________________________________________
List: Catalyst
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst/
Dev site: http://dev.catalyst.perl.org/