[Catalyst] More detailed proposal for changes related to content negotiation and REST

[Bill Moseley]

On Thu, Aug 8, 2013 at 9:27 PM, John Napiorkowski <jjn1056 at yahoo.com> wrote:

>
>
> https://github.com/perl-catalyst/CatalystX-Proposals-REStandContentNegoti=
ation
>


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'} =3D '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
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20130809/ab0ab=
fa2/attachment.htm