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

[J. Shirley]

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]

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 understand the limitations of /cd/id/{id} vs. /cd/name/{id}, but a
lookup and redirection service is a better solution that polluting
your absolute unique representative URL spaces.

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.

-J