[Catalyst] Re: Catalyst::Action::REST

Adam Jacob adam at stalecoffee.org
Mon Nov 20 17:16:36 GMT 2006


On Mon, Nov 20, 2006 at 04:02:29PM +0100, A. Pagaltzis wrote:
> OK, to lay out my own thinking a little, when I was doing my
> silly PATHINFO-based hack-up of CGI::Prototype::Hidden, the plan
> eventually became to have one class per handler, with methods
> named after, err, methods, eg.:
> 
>     sub GET  { ... }
>     sub POST { ... }
>     sub HEAD { ... }
> 
> I still think that’s cleanest approach.

It's pretty close to the same thing.  If you wanted to do this, you
could still get the benefits of the auto-serialization parts of
Catalyst::Action::Rest by having:

sub begin :ActionClass('Deserialize') {}

and

sub end :ActionClass('Serialize') {}

> Catalyst as it stands somewhat encourages a confusion between
> nouns (URIs) and verbs (methods), with URIs like
> `/entry/1234/comments/add`, where the `/entry/1234/comments` part
> identifies a resource, but the `/add` bit at the end is really an
> verb. That should simply be a POST to `/entry/1234/comments`. And
> most of the time, if the design is RESTful from the start, you
> can implement a web app as pure CRUD using the HTTP methods; eg.
> the methods in a controller should simply correspond 1:1 to HTTP
> verbs. That was as far as I had gotten my own thoughts.

I can see why that would be appealing.  It would probably not be hard to
add an option to Catalyst::Action::REST to do things that way.  If you
really wanted to do things like tunneling unsupported methods, that may
be difficult. (From within Catalyst::Action::REST)

Adam




More information about the Catalyst mailing list