<br><br><div class="gmail_quote">On Wed, Jan 27, 2010 at 1:16 PM, Tomas Doran <span dir="ltr"><<a href="mailto:bobtfish@bobtfish.net">bobtfish@bobtfish.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On 27 Jan 2010, at 15:33, Bill Moseley wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
No big deal. I was just curious why the HTTP::Body approach was not used in the existing REST/RPC modules, as that was already the place used by Catalyst to de-serialize the body. I thought maybe there was a reason I might not understood, which is why I asked.<br>
</blockquote>
<br></div>
HTTP::Body isn't really structured for this - you can (and I _do_ in one of my apps) add or override the content type handlers.<br>
<br>
However as it's class data, this is perl interpreter wide - which means that two different applications with conflicting requirements can't exist in the same mod_perl interpreter - not awesome.<br></blockquote><div>
<br>I see. So you are saying that Content-Type: application/json might need to be deserialized differently in different applications that share the same interpreter? Obviously, json could decode into an array ref so that could not be mapped to request parameters. Is that what you mean? Or that an application might want the raw json?<br>
</div><div> <br></div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>