<br><br><div class="gmail_quote">On Sat, Jan 23, 2010 at 1:40 PM, J. Shirley <span dir="ltr"><<a href="mailto:jshirley@gmail.com" target="_blank">jshirley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div><br>
</div></div><br>
If I assume that decoding is synonymous with de-serialization, it<br>
makes more sense. At first thought, I just don't think they're that<br>
similar, though. Maybe in implementations (comparing JSON to HTTP<br>
POST parameters) it is, but in the case of HTTP::Body decoding a<br>
mime64-encoded JPEG, it isn't at all.<br></blockquote><div><br></div><div><br></div><div>With a jpeg I assume the content type would be form-data (that included an upload in the form) where the file ends up in $req->uploads, not as a request parameter.</div>
<div><br></div><div>I find decoding requests analogous to Views. In my apps controllers take input (params, arguments and uploads) and the result is data in the stash. Then the View has the job of serializing (normally to HTML via template, but no reason it can't be JSON or anything else). In fact I have many controller actions that are used for both normal full-page HTTP requests and AJAX requests. So, similar to how the controller action does not know or care what view is going to be used, the controller action doesn't know or care how the request is serialized over the wire. That's how I picture it.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>From a behavior standpoint, having a POST/PUT'd JSON segment that ends<br>
up in ->params would be maddening to me. They aren't parameters, not<br>
even in the loosest of the RFC interpretations.<br></blockquote><div><br></div><div>I'm trying to understand that point of view. Why is that maddening? If you have a request serialized as json then $req->parameters would go unused and instead have the deserialzed request end up some place else, say as $req->data?</div>
<div><br></div><div>I have an XMLRPC API to an application. I implemented it by creating an HTTP::Body subclass that parses the XMLRPC XML body. The <method> ends up mapped to an action, the <params> ends up as body parameters, and <base64> elements end up as uploads. As a result existing controller actions can be used for both XMLRPC request and for normal web requests. All I have to do to expose the action in the API is add XMLRPC( $method_name ) as a action attribute.</div>
<div><br></div><div>Catalyst::Engine hard-codes HTTP::Body. I think it would be more flexible if the body parser class could be a config option (to allow easy sub-classing), -- similar to how the request class can be defined -- but it's not that difficult to set up now. Just have to add the content type to %HTTP::Body::TYPES.</div>
<div><br></div><div>Thanks for your comments, I appreciate the feedback.</div><div><br></div></div><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>