Opened 8 years ago
Closed 8 years ago
#27415 closed New feature (wontfix)
Add request.JSON or request.get_json()
Reported by: | Ustun Ozgur | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 1.10 |
Severity: | Normal | Keywords: | json, request, incoming data |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If the content-type is application/json, the body should be parsed and put on request object as JSON or json field (or retrieved via a method like get_json).
This is what flask does, and should be supported for convenience since it is nowadays very common to ingest JSON.
I have seen several proposals in this regard, but those seem over generic (ability to support multiple parsers etc.) and work on them seems to have stalled or moved to libraries.
Solving the majority case where people use JSON should be good enough.
I have searched the open tickets, but haven't been able to find a duplicate which just focuses on JSON.
https://code.djangoproject.com/ticket/21442
https://github.com/django/deps/blob/master/draft/content-negotiation.rst
https://flask.readthedocs.io/en/latest/api/#flask.Request.get_json
The json class might be configurable so that people can use ujson instead of stock json for perf if needed.
Change History (2)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Component: | Core (Serialization) → HTTP handling |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Hi Unstun,
Thanks for your suggestion but I believe we should focus on making
request.data
available based on theContent-Type
header like described in the DEP you linked instead of adding aJSON
attribute on request that would be removed in the mid-term. In the meantime you can write a middleware that adds aJSON
attribute on request with the appropriate content-type if you want to rely on that.