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:	J. Shirley
Date:	5 May 2008

On Mon, May 5, 2008 at 10:02 AM, Matt S Trout <dbix-class> wrote:
>
> On Mon, May 05, 2008 at 07:50:08AM -0700, J. Shirley wrote:
> > On Mon, May 5, 2008 at 4:31 AM, Matt S Trout <dbix-class> wrote:
> > >
> > > On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley 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.
> > >
> > > I fail to see how whether the PK is the lookup key or not has any
> > > relevance at all to the original point, which was "your lookup key and
> > > names of actions might clash so it can be nice to have an extra path component
> > > such as 'id' for the lookup part to disambiguate".
> > >
> > >
> >
> > Because I'm talking about REST and a verb in the URI doesn't need to be there.
>
> You'd never have a /user/recent or similar URL? I guess if you assume that
> all views onto the collection are done via query parameters, or just
> move that funcationality to /recent-users or similar then it doesn't matter.
>
> But that's a different sort of uglification of the URL; it doesn't get rid
> of it.
>
> And it still doesn't help if you want to allow lookup by more than one
> name so far as I can see.
>
>

Search vs. Browse is separate user actions and deserves separate resource space.

/user implies a single user.
/users implies browsing.

So in this hypothetical case I would probably have a top level
namespace for /browse that had its own hierarchy (since most people
are going to browse more than just people)
/browse/users/recent

But... I also would do /browse/people/recent

Now you have a better (read-only) browse namespace on your site and it
descends into a hierarchy appropriately.

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