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

[luke saunders]

On Mon, May 5, 2008 at 9:29 PM, J. Shirley <jshirley at gmail.com> wrote:
>
> On Mon, May 5, 2008 at 1:10 PM, luke saunders <luke.saunders at gmail.com> wrote:
>  >
>  > On Mon, May 5, 2008 at 6:16 PM, J. Shirley <jshirley at gmail.com> wrote:
>  >  >
>  >  > On Mon, May 5, 2008 at 9:51 AM, luke saunders <luke.saunders at gmail.com> wrote:
>  >  >  > On Mon, May 5, 2008 at 5:19 PM, J. Shirley <jshirley at gmail.com> wrote:
>  >  >  >  > On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland <arodland at comcast.net> wrote:
>  >  >  >  >  > On Monday 05 May 2008 09:50:08 am 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:
>  >  >  >  >  >
>  >  >  >  >  > > >  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.
>  >  >  >  >  >
>  >  >  >  >  >  But those nouns you're talking about aren't verbs at all.
>  >  >  >  >  >
>  >  >  >  >  >  Andrew
>  >  >  >  >
>  >  >  >  >  How is /create, /edit or /delete not a verb?
>  >  >  >  >  My argument is separate to the /create is valid in the /foo/{token}
>  >  >  >  >  bit.  I'm saying that /foo/create is silly to have in the first place ...
>  >  >  >
>  >  >  >  Okay, let me clear this up. Originally the plan was to have a
>  >  >  >  centralised REST-style action which dispatched POST/PUT/GET/DELETE
>  >  >  >  requests to the appropriate actions while also providing RPC-style
>  >  >  >  verb actions as an alternative for use if the client didn't properly
>  >  >  >  support the REST request methods. Having listened to discussion in
>  >  >  >  this thread I think it would be better to make the module pure REST
>  >  >  >  and then provide the RPC alternative through a subclass, perhaps also
>  >  >  >  integrating Catalyst::Request::REST::ForBrowsers into the REST version
>  >  >  >  as suggested.
>  >  >  >
>  >  >  >
>  >  >  >  >  If you apply actual REST principles, you don't have such nonsense.
>  >  >  >  >  But again, as I said, this is if you are working with REST.  If REST
>  >  >  >  >  doesn't fit your application model, don't use it.  Just don't name
>  >  >  >  >  things REST when they are really CRUD.
>  >  >  >
>  >  >  >  Why can't CRUD be RESTful?
>  >  >  >
>  >  >  >  In fact my revised plan is to glue together a base REST module and a
>  >  >  >  base CRUD module and add the list method discussed somewhere else in
>  >  >  >  this thread to provide a complete default RESTful module. Ideally the
>  >  >  >  REST base module could be swapped for an RPC style base module to
>  >  >  >  easily provide an RPC alternative of the same thing.
>  >  >  >
>  >  >
>  >  >  REST and CRUD are not mutually exclusive, but implementations can be.
>  >  >
>  >  >  When I see things like /book/create, /book/1/edit I see CRUD (or RPC)
>  >  >  but not REST.  REST also doesn't have to be CRUD.  I have a REST
>  >  >  application that is more CR.  It just posts immutable records and
>  >  >  provides findability on those records.
>  >  >
>  >  >  The discussions about a better CRUD base class with REST and RPC
>  >  >  adapters is obviously the better (best?) solution, but I also think
>  >  >  there will be significant disagreement between appropriate URI
>  >  >  resource conventions (as my exchange with zby is an example of.)  I
>  >  >  haven't had enough time to actually proffer any code, but since this
>  >  >  is a central focus of my development as late I'm very opinionated in
>  >  >  these matters :)
>  >
>  >  I think that the /foo/{token} vs /foo/id/{token} is the only point of
>  >  contention. And it would definitely be nice if an agreement could be
>  >  reached on this. Indeed, if I do develop this further it would make
>  >  sense if the REST base class is your own
>  >  Catalyst::Controller::REST::DBIC::Item.
>
>  If people are ok with the verbs being in the URL as a sacrifice to
>  broken browsers, agreed :)

I think the consensus is probably the opposite. I already agreed that
the verbs shouldn't be in the REST module but there should be an RPC
variant.

>  I'm going to be rounding out the tests for my work, and I'm giving a
>  talk on it at YAPC::Asia.  It's mostly just my thoughts on how things
>  go, but the work is from a web-services point of view, with some
>  browser views.  I'll post my slides up (and there may be video fo the
>  talk) afterwards.

Nice.

>  >  To me the /foo/{token} URI is only acceptable if it is understood that
>  >  no further custom object level URIs can then be added
>  >  (/foo/{token}/disable for example) and that lookup can only ever be by
>  >  {token} rather than {name} or something else. For REST I can see that
>  >  this is possible but I do feel that putting something between the base
>  >  and the token to clearly identify it as object level is generally the
>  >  safest option.
>
>  I like to map my URLs out in a definitive hierarchy.  If people want
>  an implicit create action, a /foo/-/create looks better to me than
>  having /foo/create, because I have the level of /foo to be the plural,
>  /foo/{id} to be the singular (in a simple CRUD example).
>  /foo/-/create is fine, because you can have a rule that "-" is never
>  an acceptable record identifier.

I think that's a pretty reasonable suggestion. It doesn't solve the
different object lookup methods point, but I think it's reasonable for
that to justify a subclass.

However, I do still have a nagging feeling that having /foo/create and
/foo/-/{token} is preferable because it's easier to not make an action
with a PathPart of "-" than it is to not have a record whose identifer
is "-". But I accept that your method would mean that the "-" is only
seen if you want non-standard methods.

>  All of this stuff is mostly just standardizing on a set of ideas,
>  which leads into your next point:
>
>
>  >  Peter made a fair point that if you don't like it you can subclass and
>  >  change, but agreeing on a best practice and making that default is
>  >  obviously desirable.
>
>  Agreed :)
>
>  My vote is hierarchy like:
>   /foo
>        /{token}   # Can be pk1 if you so desire
>        /-             # - is never acceptable as an identifier
>           /create # if you want an empty action here

I think that's fine.

>  Now, I do vote against having an explicit create action, since "POST
>  /foo" (or "POST /foo/{token}") seems to be a more reasonable create
>  action.

Agreed :-)