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

[luke saunders]

On Sun, May 4, 2008 at 6:05 AM, J. Shirley <jshirley at gmail.com> wrote:
>
> On Sat, May 3, 2008 at 9:29 PM, Patrick Donelan <pat at patspam.com> wrote:
>  >
>  > > And this gets you the following endpoints to fire requests at:
>  > >    /api/rest/cd/create
>  > >    /api/rest/cd/id/[cdid]/update
>  > >    /api/rest/cd/id/[cdid]/delete
>  > >    /api/rest/cd/id/[cdid]/add_to_rel/[relation]
>  > >    /api/rest/cd/id/[cdid]/remove_from_rel/[relation]
>  >
>  > Those URLs don't strike me as very RESTful.
>  >
>  > Patrick
>  >
>
>  That is my first impression.  My work is an enhancement from
>  Catalyst::Action::REST, which is a great module already out on CPAN
>  and used by other people (holoway++).
>
>  I'm all for collaboration, but my work is mostly tied to have exposed
>  webservices (in addition to a web-browser compatibility layer) via
>  REST.  By that I mean that I expect, and require, that I can do a PUT
>  /api/rest/cd/[cdid], DELETE /api/rest/cd/[CDID]
>

Sure, but I have previously had problems getting a browser to send PUT
requests from JS so separate endpoints were required. In fact the Dojo
author even said that PUT was a nightmare, use POST (possibly fixed in
recent Dojo version / browsers). i see no reason why you can't have
one base action which forwards to the others based on request type so
that both URL types are exposed.

>  On a side note about REST - REST doesn't mean human readable URLs.  It
>  means representative URLs.  The bit about cd/id/{CDID}/ smells like
>  named parameters going into positional parameters.  What is the real
>  difference between cd?id={CDID}&action=delete, aside from different
>  characters?  Where as with REST, /cd/{id} is a unique identifier for
>  that object and hence a full representation.
>

I find having the id in the path to be a clearer distinction between
object level operations and class level operations. It's the
difference between object and all objects.

>  You can catch me on IRC next week, as I'm actively working on this for
>  $work and it's getting real dev time (finally).  My work is
>  functionally complete, but lacking test cases; it is just a refactor
>  of existing code in production.
>

So you don't want to automate any actual operations? In which case if
anything my module could subclass yours.