On Mon, May 5, 2008 at 4:31 AM, Matt S Trout <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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.
If we were talking about RPC, that would be a differently titled
thread and different arguments.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/