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)

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 1:10 PM, luke saunders <luke.saunders> wrote:
>
> On Mon, May 5, 2008 at 6:16 PM, J. Shirley <jshirley> wrote:
> >
> > On Mon, May 5, 2008 at 9:51 AM, luke saunders <luke.saunders> wrote:
> > > On Mon, May 5, 2008 at 5:19 PM, J. Shirley <jshirley> wrote:
> > > > On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland <arodland> 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> 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'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.

> 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.

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

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.

-J

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