On Thu, Aug 8, 2013 at 9:27 PM, John Napiorkowski <jjn1...@yahoo.com> wrote:
> > > https://github.com/perl-catalyst/CatalystX-Proposals-REStandContentNegotiation > I currently extend HTTP::Body in a similar way that you describe. But I have them a separate classes so I just do: use My::Multipart; then in that I hack in my type for HTTP::Body: package My::MultiPart; use HTTP::Body; $HTTP::Body::TYPES->{'multipart/form-data'} = 'My::MultiPart'; As you propose, mapping a mime type to a sub seems pretty flexible. I assume the sub could return a filehandle. File uploads still need to stream the uploads to disk while making the parameters available as HTTP::Body does now. I like the regex mimetype keys, but should they be an array instead of a hash so can set the order checked? I think we must consider large inputs/streams. You say $_ is the request content. Is that the full request with headers? Is the request already de-chunked, for example? Or am I thinking too low level? In some apps I'm using Catalyst::Action::REST and others I have some custom code where I use HTTP::Body to parse JSON. I'm mixed about having the request data end up in $c->req->parameters vs $c->req->data. I don't really see why form-data/urlencoded should be treated differently than other encodings like JSON. I not quite sure about $c->res->body( \%data ); I think body should be the raw body. What does $c->res->body return? The serialized json? The original hashref? If a parser dies what kind of exception is thrown? You say they would not set any response status, but wouldn't we want to catch the error and then set a 400? (I use exception objects that carry http status, a message to return in the body and a message used for logging at a given level.) I'm not sure what to think of the Provides and Consumes controller attributes. It's one thing to realize early that the client cannot handle any response I'm willing to provide (json, yaml, whatever), but I'm worried this would blur separation of concerns. That is, by the time the controller runs we would have already decoded the request and want to just work with the data provided. And would we want different data returned if the client is asking for json vs yaml? Maybe I'm missing the point of that. BTW - I practice I find it pretty handy to be able to specify/override response encoding via a query param. -- Bill Moseley mose...@hank.org
_______________________________________________ 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/