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 = {
'application/octet-stream' => 'HTTP::Body::OctetStream',
'application/x-www-form-urlencoded' => 'HTTP::Body::UrlEncoded',
'multipart/form-data' => 'HTTP::Body::MultiPart',
'multipart/related' => 'HTTP::Body::XFormsMultipart',
'application/xml' => '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
mose...@hank.org
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
