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

[Will Crawford]

On 13 August 2013 16:37, John Napiorkowski <jjn1056 at yahoo.com> wrote:
[...]
> The main issue that I see is that we have too many ways to do exactly the same thing (return JSON for AJAX endpoints) and no clear reason why any of them are better for a given purpose.  Additionally, some of them are a bit verbose, and Catalyst already has reputation for being the long way to do simple things.
>
> However it does seem to me after we've all talked about it quite a bit that at this point there really doesn't seem to be a really exciting approach that would be useful (talking about a common way to handle the serialize / format stuff, like allowing res->body to take a ref and convert it to JSON or XML, etc.)   At least in terms of something that belongs in Catalyst core.  Why not lets pull that part out of the spec and make it a separate research project, and for now continue to let the community play with various approaches.  I think there appears to be less controversy on the request side, in terms of building in alternative content parsing, and possibly a first go at subroutine attribute content type negotiation.
>
> Any thoughts on the request side of the proposal?

Ultimately, from my own experience of doing XML / JSON /
whatever-encoded requests and responses, is:

· I needed to be able to specify, *once I'd dispatched the request* to
be able to
  - deserialise the request
  - set a flag in the request or response to indicate that the latter
needed serialising

Being able to put an attribute on an action, e.g.

    : DeserializeUsing(method_name) SerializeResponseUsing(other_method_name)

would be kinda cool, although I settled for pushing callbacks onto a
list in $c->stash for the latter, and deserialising in part of a chain
that was shared by all the requests that needed it. Sometimes you want
a handful of AJAXy actions in amongst mostly-normal templated HTML
page, though, so being able to label just one or two actions in a
controller that way would be neat. All quite unnecessary, can do it by
hand where needed, etc., but handy.