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

[Peter Karman]

On 05/05/2008 02:33 PM, luke saunders wrote:
> On Mon, May 5, 2008 at 7:28 PM, Peter Karman <peter at peknet.com> wrote:
>>
>>  On 05/05/2008 12:16 PM, J. Shirley wrote:
>>
>>  >
>>  > 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.)
>>
>>  As has been mentioned before, there is an existing REST + CRUD implementation already on CPAN:
>>
>>  http://search.cpan.org/dist/CatalystX-CRUD/lib/CatalystX/CRUD/REST.pm
>>
> 
> Out of interest, why did you not use Catalyst::Controller::REST here?
> 

A few reasons.

One, the CRUD::REST primary design goal is to allow you to simply change your @ISA list in
order to switch from RPC to REST style URIs. If you are already using a
CX::CRUD::Controller-based class, you just put CX::CRUD::REST at the front of your @ISA
list and voila. That goal would have required a bit more method aliasing and other hackery
in order to support the *_VERB API in C::C::REST.

Two, the C::C::REST module (and related Action class) have a lot of support for automatic
serialization. CX::CRUD is completely agnostic about response type. Maybe it shouldn't be.
But it is.

Three, C::C::REST does not have "real-world" browser HTTP use in mind, as
REST::ForBrowsers does. That's not bad; it's just more "pure" imo. CX::CRUD tries to
support both, and as of yesterday, svn has support for the 'x-tunneled-method' param like
REST::ForBrowsers does.

Four, I didn't need the overhead. :)

Having said all that, I expect that C::C::REST could work well with CX::CRUD::REST, and
I'd love to see a patch that implements it, bearing in mind the points above.

-- 
Peter Karman  .  peter at peknet.com  .  http://peknet.com/