Following up on our recent simulating discussion on adding an API to an application, I wonder is someone can help me understand something:<br><br>Catalyst uses HTTP::Body to parse body content. It currently handles these request content types:<br>
<br>our $TYPES = {<br> 'application/octet-stream' => 'HTTP::Body::OctetStream',<br> 'application/x-www-form-urlencoded' => 'HTTP::Body::UrlEncoded',<br> 'multipart/form-data' => 'HTTP::Body::MultiPart',<br>
'multipart/related' => 'HTTP::Body::XFormsMultipart',<br> 'application/xml' => 'HTTP::Body::XForms'<br>};<br><br>But, Catalyst::Controller::DBIC::API and Catalyst::Controller::Rest both use Catalyst::Action::Deserialize.<br>
<br>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?<br><br>I'm just wondering if I'm missing some important reason why these other request content types are handled differently.<br>
<br>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.<br>
<br>So, why different approaches to decoding request body content?<br><br> <br clear="all"><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>