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

[John Napiorkowski]

On Wednesday, August 14, 2013 5:53 AM, Will Crawford <billcrawford1970 at gmail.com> wrote:

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
>

I think the first half of the proposed spec would offer support for this, although at the application not controller or action level.  I'd like to see it 'down the stack' but I think also its a fair iteration and adds a lot of value to have it globally in the request object.  Eventually we'll expose at the action level a req->body_fh for when you need to have more custom handling.  My main issue is that it feels not worth the trouble since the most popular PSGI handers typically buffer request input anyway.  So for now making this a request object function seems like the correct approach.

>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.
>
>

Yes, and this is the part where for these types of services (RESTful service, basic JSON RPC, ajax endpoints) the View part of MVC can often feel not particularly useful.  Or maybe it should be but we are not doing it right :)  This is why the initial proposal laid out some ideas about just serializing directly in the response object (the flip side of deserializing globally in the request object).  However unlike with the request object, there's no underlying architectural reason driving this.

I did a mock up similar to the subroutine attribute approach you outlined, FWIW, there's a working prototype on github, which I've shared earlier, http://github.com/jjn1056/CatalystX-Example-Todo which is just an action role.

John