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 9:49 AM, Zbigniew Lukasiak <zzbbyy> wrote:
>
> On Mon, May 5, 2008 at 6: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,
> > and the /foo/id/{id} is nothing more than a conversion from named
> > parameters to positional, and ugly.
> >
> > 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.
>
> The point is about having something that will work as REST for
> automated agents and also work for browsers by some emulation or what
> ever - so you'll have some additional actions on the controller as
> well. Additionally if we really want to make this REST Role (assuming
> Moose Catalyst by that time) - then the user of the library can have
> his own actions. In both way you'll have a clash if we go your way.
>
> Because /foo/id/{id} looks like a parameter - which is the only
> argument agains it and is just a bit of pedantry on your side - you
> would allow for broken logic?
>

That's just one argument that is most obvious. The other argument is
that it adds additional entry points into an entity that you have to
keep in sync.

If you have /foo/id/{id} and /foo/name/{name} that are two paths to
the same entity, but {name} is not immutable you have broken
navigation at some point (bookmarks, etc). So you have two immutable
entities for the same thing? I fail to see why that works. Which
leads into my main argument that using the primary key as the record
lookup identifier (in many cases) is simply bad design.

This strategy is redundancy of the oddest form to me, and it yields
more complications down the road as applications become more complex.

If you remove the redundancy, and each object has a well-defined
identifier, a POST to /foo will create a new entity which redirects to
/foo/{identifier}. It's easy to duplicate functionality that a POST
to /foo/{identifier} works the same as a POST to just /foo, and can
generate $identifier. I fail to see why a /create action needs to
exist in the first place on /foo.

Now, for browser-compatibility methods it isn't a bad thing having
/foo/{identifier}/(edit|delete). The business with /foo/id/{ident}
there so that you don't conflict with a "/create" action on /foo is
just silly, and a sign of inadequate forethought into your resource
structure. But again, this has very little to do with REST and more
to do with a sane URI structure (although not having an explicit
/create action is more on the RESTful side, I never have encountered
an issue having "POST /foo" handle item creation).

So, yes, it is pedantic but I don't view it as broken logic. I view
it as tidy logic that doesn't employ the use of URI hacks to get
around browser deficiencies.

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