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)
. . . . . \ Zbigniew Lukasiak (16 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:	Zbigniew Lukasiak
Date:	4 May 2008

On Sun, May 4, 2008 at 6:06 PM, J. Shirley <jshirley> wrote:
> 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.

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/

_______________________________________________
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/