request.DATA is sometimes QueryDict, sometimes dict

[Joshua Pokotilow]

Whether or not it's a dict or a QueryDict seems to depend on the code path used to POST the request.

For example, if the request body contains JSON and it gets parsed by parsers.JSONParser from Request._parse(), a dict is returned.

OTOH, if the request is posted from a form and I access Request.method before touching Request.DATA, then Request._perform_form_overloading() sets Request._data to Request._request.POST, which is a QueryDict.

Consistency here would be nice.

[Tom Christie]

Maybe.  Although there is a reason there's a difference.   Different encodings support different data structures.  Form data is an encoding that supports multiple keys of the same value, whereas json is an encoding that doesn't.

As it happens for JSON data, request.DATA may not even be a dict at all, it could equally well be a list, boolean or any of the other json primitives.

It's possible we could specifically handle the case where the top level obj is a dict, and use a queryset there, but in general I'd say that the right approach is to not depend on request.DATA not necessarily returning a QueryDict unless you're only using the form parsers.

[Joshua Pokotilow]

Hmm, I see your point. What tripped me up specifically is that I implemented a service that expected a list for one of its parameters. When I was playing around with said service using the HTML forms DRF exposes, I noticed the form only submitted one element in lieu of a list, so I called request.DATA.getlist() and the problem seemed solved. Unfortunately, my tests failed since they use JSON instead of form submissions.

I'm not sure I would special-case request.DATA. Might make more sense to add a get_querydict() method that returns None if the serialized result isn't a QueryDict, or something. Not sure I'm a big fan of that idea either, though.