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

[J. Shirley]

On Mon, May 5, 2008 at 9:49 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>
> On Mon, May 5, 2008 at 6: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,
>  >  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