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

[J. Shirley]

On Mon, May 5, 2008 at 10:02 AM, Matt S Trout <dbix-class at trout.me.uk> 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 at trout.me.uk> 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 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.
>  > >
>  > >  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.