--
Ticket URL: <https://code.djangoproject.com/ticket/32646>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Collin Anderson):
PR: https://github.com/django/django/pull/14258
--
Ticket URL: <https://code.djangoproject.com/ticket/32646#comment:1>
* status: new => closed
* resolution: => duplicate
Comment:
As far as I'm aware, it's a duplicate of #27415.
--
Ticket URL: <https://code.djangoproject.com/ticket/32646#comment:2>
* cc: Adam Johnson (added)
Comment:
I think this also relates to #32259. Completing the
[https://github.com/django/deps/blob/main/draft/content-negotiation.rst
content negotiation story] as suggested on #27415 would be the
''significant benefits'' justifying changes in #32259. 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/32646#comment:3>
Comment (by Adam Johnson):
There's also #21442 for Tom Christie's work.
I think adding `request.json()` would be a bit of a mis-feature, when we
could instead add `request.data` with a parsing framework that's more
"future-proof". It would be based on DRF's behaviour, so would be familiar
to most Django devs already.
--
Ticket URL: <https://code.djangoproject.com/ticket/32646#comment:4>
Comment (by Collin Anderson):
I can see the case for content negotiation.
My two sense: In browsers, there's a standard `.json()` method for http
responses [0], and the Python `requests` library also has `.json()`
method, so a simple `.json()` method is becoming more of the norm for a
lot of simple use cases.
I don't think I'd be wrong if I said most apis only need to speak json.
Content negotiation, while needed for some use cases, is probably overkill
for many people's. Some people aren't going to want their endpoint to
accept xml and yaml.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Body/json
--
Ticket URL: <https://code.djangoproject.com/ticket/32646#comment:5>