Tom,
I agree that the middleware solution is not the best and in my mind creates
fragmentation of the same type of request handling.
A generic content-type framework would make the request parsing more
flexible, stronger to change in the future and open the door to any type.
I'm curious about the choice of request.DATA though, when doing a POST
request, I expect the data to be in the POST dictionary and nowhere else.
Creating a request.DATA attribute would break compatibility with old code
and seem to me less intuitive. Where should request.FILE go in that case?
Would request.POST just be a call to request.DATA?
Stefan
On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote:
>
> Hi Stefan,
>
> Sure, I'd be interested in seeing us improve how we deal with JSON
> requests and responses.
>
> My preference would be to introduce a request parsing and response
> rendering API that allows us to support not just JSON, but any media type
> that has a parser installed for it. (I've commented on some of this
> before,
> here<https://groups.google.com/forum/#!searchin/django-developers/tomchristie%7Csort:date/django-developers/Qr0EorpgYKk/6qyCrVqZwmMJ>,
>
> although I think I'm warming towards the idea that it's probably about time
> we started addressing at least some of this in core.)
>
> Unsurprisingly I'd suggest the same general approach that is used in REST
> framework - A lazy `request.DATA` attribute (or similar) that when
> accessed, inspects the media type on the request, and parses the request
> stream with an appropriate parser if possible. The installed parsers can
> be configured globally, or on a per-request basis. The existing multipart
> and form-encoded parsing behaviour would no longer be a special case baked
> directly into the request object, but instead be the default installed
> parsers.
>
> Taking this approach makes it trivial to write views that can handle both
> JSON and form data, and providing a proper parser API makes it easy for
> developers to package up and share their own parser implementation, such as
> YAML, XML and MsgPack. (And, looking forwards, JSON-based media types such
> as hypermedia types.)
>
> In REST framework this behaviour is (by necessity) implemented in a
> Request object that wraps the underlying HttpRequest, but the same basic
> implementation can be applied to implementing it directly in the Request
> object, and would be somewhat easier.
>
> I'm interested to see Marc suggesting middleware specifically for handling
> JSON requests. That'd work, and would be a simple approach. My
> reservations with that would be:
>
> * We'd not be making it any easier for users to deal with request parsing
> generally.
> * There's no way to write views that deal with request data in an
> agonistic way, and dealing with differing media types would require
> switching based on the media type in the view itself. For example, the
> generic views would still only support form data. As another example, if
> you wanted to add, say, MsgPack support to your application, you'd need to
> re-write all your views.
>
> From my point of view this is already a solved problem, and I'd really
> like to see a generic approach to handling request data, and a
> corresponding approach to rendering responses into an appropriate media
> type.
>
> All the best,
>
> Tom
>
> On Tuesday, 3 September 2013 06:30:04 UTC+1, Stefan Berder wrote:
>>
>> Hi,
>> I looked around the list and couldn't find any mention of this subject.
>>
>> In `django.http.request.HttpRequest._load_post_and_files()` there is
>> explicit mention of two content type ('multipart/form-data' and
>> 'application/x-www-form-urlencoded'), any other content type will get empty
>> values for self._post.
>>
>> Given that a lot of user form interaction is now happening through
>> 'XMLHttpRequest', I think that the 'application/json' content type should
>> be supported. A lot of javascript libraries will use json as the default
>> format:
>> * angularjs: http://docs.angularjs.org/api/ng.$http, see "Setting HTTP
>> Headers"
>> * emberjs:
>> https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L974
>> * backbone: http://backbonejs.org/#Sync
>> * jquery: http://api.jquery.com/jQuery.ajax/ (the only one using
>> 'application/x-www-form-urlencoded' by default)
>>
>> I'm trying primarily to create a discussion on the subject and am ready
>> to provide the code for it as I had to write it. This would help avoid
>> hacks to handle the request object in my view.
>>
>> I know there are some apps to han
