Add json_response funciton

[asvetlov]

Should be derived from aiohttp.web.Response.

Constructor signature is:
def __init__(self, data, *, status=200, reason=None, headers=None)

Should pack data arg as json.dumps() and set content type to application/json.

People forget to specify proper content type on sending json data.

[sloria]

Any preference as to if/how the json module should be specified?

• Fallback

try:
    from simplejson as json  # or anyjson? ujson?
except ImportError:
    import json

• Class variable

import json

class JSONResponse(Response):
   json_module = json
    #...

[asvetlov]

I think constructor parameter dumps=json.dumps (like https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/client_reqrep.py#L728) should be enough for the issue.

Another pull request may try to solve global configuration problem. See discussion for #336 also.

[sloria]

Any reason not to pass in the json_module=json, just in case we ever need to deserialize JSON.

Hypothetical use case:

class JSONResponse(Response):

    @classmethod
    def from_json(cls, json_string: str, **kwargs):
        return cls(data=self.json_module.loads(json_string), **kwargs)

[asvetlov]

I don't see use case for deserialization of response.
web.Request has .json() coroutine for deserializing request https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/web_reqrep.py#L326

Different libraries may have different functions for unpacking data but I pretty sure all of them provides callable accepting dict and returning string.
Also I may want to use custom encoder/decoder: https://docs.python.org/3/library/json.html#encoders-and-decoders

[ludovic-gasc]

Hi,

If you could do something like that: https://github.com/Eyepea/API-Hour/blob/master/api_hour/plugins/aiohttp/__init__.py

It means we'll can remove this file: less code in API-Hour, better is ;-)

We use a lot this helper.

In this file, we have also an helper to output HTML files, be my guest to do something similar.

[asvetlov]

I'm not reluctant for adding HTMLResponse too.
Perhaps we need another issue for that.
@GMLudo would you file this one?

[jashandeep-sohi]

@asvetlov
Why not just leave JSON serialization to the user, like in HTMLResponse?
Like you said, the problem is that people forget to set content-type: application/json, not serialization.
IMHO, a simple class that forces the content-type to application/json should suffice.

[asvetlov]

@jashandeep-sohi I believe JsonResponse(json.dumps(data)) looks uglier than JsonResponse(data).

Advanced user may provide serializer is needed.

[kxepal]

Should pack data arg as json.dumps() and set content type to application/json.

I only note, that content-type should be easily customized and not just as constant value, but with the respect of Accept header. Cases:

1. When we develop API and use own JSON MIME type like application/vnd.my-company+json;
2. When we need to return text/plain for browsers in order to let us safely open API url in it and see the response instead of being asked to download some cryptic file. However, for explicit Accept application/json we must return expected application/json Content-Type. Tradeoffs for usability are hard.

These details makes life a bit complicated, but not too much.

[kxepal]

I believe JsonResponse(json.dumps(data)) looks uglier than JsonResponse(data).

Agree. It's also quite awkward that JsonResponse doesn't know how to transform data into JSON.

[jashandeep-sohi]

@kxepal
Well, neither will HTMLResponse, if that's ever added.

@asvetlov
Depends on you perspective, I suppose. I wouldn't say its uglier, but more verbose.

So, how would one go about returning a cached JSON string using this scheme?

[kxepal]

@jashandeep-sohi basically, all these *Response is about to get some data, pass it through render function and form HTTPResponse with proper related metadata (status, headers, payload etc.).

For JsonResponse this renderer is json.dump or whatever, for HTML one is jinja.render or special bridge to php or whatever. So both objects shares similar protocol and workflow. What you only need is to be able customize their behavior and be sure to not violate it.

[jashandeep-sohi]

Okay, so HTMLResponse would have a similar dumps argument to the constructor?

[asvetlov]

@jashandeep-sohi I take you proposal for adding dumps arg to HTMLResponse and a joke to stress your opinion.

But yes, we can relax parameter list a bit to make both content_type and data optional. User may override content type if needed and pass non data positional arg but text or even body named args.

Anyway, I feel we need Pull Request for further discussion.

Volunteers?