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>    &#39;application/octet-stream&#39;          =&gt; &#39;HTTP::Body::OctetStream&#39;,<br>    &#39;application/x-www-form-urlencoded&#39; =&gt; &#39;HTTP::Body::UrlEncoded&#39;,<br>    &#39;multipart/form-data&#39;               =&gt; &#39;HTTP::Body::MultiPart&#39;,<br>

    &#39;multipart/related&#39;                 =&gt; &#39;HTTP::Body::XFormsMultipart&#39;,<br>    &#39;application/xml&#39;                   =&gt; &#39;HTTP::Body::XForms&#39;<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&#39;t it HTTP::Body&#39;s job to decode the body based on the content-type of the request?<br><br>I&#39;m just wondering if I&#39;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-&gt;req-&gt;params and controllers could be oblivious to the encoding of the request (similar to how we don&#39;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&#39;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>