[Catalyst] How to de-serialize json?

[Bill Moseley]

Following up on our recent simulating discussion on adding an API to an
application, I wonder is someone can help me understand something:

Catalyst uses HTTP::Body to parse body content.  It currently handles these
request content types:

our $TYPES =3D {
    'application/octet-stream'          =3D> 'HTTP::Body::OctetStream',
    'application/x-www-form-urlencoded' =3D> 'HTTP::Body::UrlEncoded',
    'multipart/form-data'               =3D> 'HTTP::Body::MultiPart',
    'multipart/related'                 =3D> 'HTTP::Body::XFormsMultipart',
    'application/xml'                   =3D> 'HTTP::Body::XForms'
};

But, Catalyst::Controller::DBIC::API and Catalyst::Controller::Rest both use
Catalyst::Action::Deserialize.

My question is this:  why use an action class instead of extending
HTTP::Body to deserialize the content?  Isn't it HTTP::Body's job to decode
the body based on the content-type of the request?

I'm just wondering if I'm missing some important reason why these other
request content types are handled differently.

Seems like HTTP::Body is the correct place to do all decoding.  Decoded
JSON, for example, would just end up in $c->req->params and controllers
could be oblivious to the encoding of the request (similar to how we don't
really care how params are decoded if the body is x-www-form-urlencoded or
form-data).   True, could end up with a request parameter that is a hashref,
but I don't see anything wrong with that as long as parameters are validated
correctly.

So, why different approaches to decoding request body content?



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100123/9e8de=
b2a/attachment.htm