The thing with request.POST is that it's kinda unintuitive when extended to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data was renamed request.body.
request.POST would behave in the expected traditional web way of picking up form encoded POST data, which would also be available in request.DATA as well, but request.DATA is the "new" way of doing it. Personally, I'd lowercase it though, to remove confusion with the PHP $POST $GET $REQUEST which we mimic on the request object. The generally have different use cases anyway - one for complex web things and the other for standard web browsers. (the above is what tom said...) Tom - what else do you have in DRF's Request that you would need? On 4 September 2013 12:56, Tom Christie <christie....@gmail.com> wrote: > > Creating a request.DATA attribute would break compatibility with old > code and seem to me less intuitive. > > The implementation would ensure `request.POST` would still be populated > for form data. > > There wouldn't have to be any backwards incompatible changes, and usage of > `request.DATA` (or whatever better name there might be, perhaps simply > `request.data`) would be entirely optional for using with generic request > parsing, instead of form data only. > > > > Where should request.FILE go in that case > > request.FILES would be populated by form data as normal, and would be > empty on JSON or other submissions. In order to support multipart parsing > the request parsing API would need to provide for parsers that support file > upload, in a similar way that REST framework currently does. > > > Would request.POST just be a call to request.DATA? > > That's an open question, but I'd probably expect it to only return data if > the request contains multipart or url-encoded form data. (Ie. the > behaviour wouldn't change.) > > Cheers, > > Tom > > On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote: >> >> 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<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<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/<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 handle API construction (django-tastypie, >>>> django-rest, django-piston and certainly others) they use either request >>>> wrappers or request handling in their views. >>>> >>>> Stefan >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
