Excerpts from Bill Moseley's message of Sat Jan 23 19:45:28 -0500 2010: > On Sat, Jan 23, 2010 at 1:40 PM, J. Shirley <jshir...@gmail.com> wrote: > > > > > > > If I assume that decoding is synonymous with de-serialization, it > > makes more sense. At first thought, I just don't think they're that > > similar, though. Maybe in implementations (comparing JSON to HTTP > > POST parameters) it is, but in the case of HTTP::Body decoding a > > mime64-encoded JPEG, it isn't at all. > > > > > 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.
That assumption may hold true for *your* applications, but he didn't say anything about a form or even a web browser. It's perfectly reasonable, especially in the context of REST APIs, to talk about non-form-based request bodies. (I've written actions that accepted PUT requests with a content-type of application/vnd.ms-excel, for example.) hdp. _______________________________________________ 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/