To weight in from an author of a different API tool.... In django-nap there's a simple "get_request_data" method which, essentially, determines how to parse the request according to the content type. However, currently each API only supports a single serialiser format [and HTTP Form encoding] so there's little guessing involved.
However, I wouldn't want to see the same on Request, unless there was also a direct way to imply the type you want. For instance, if I get a request that's in XML, and I ask for request.JSON, I'd like it to either yield empty or raise an error. Whereas when I didn't case, accessing request.DATA would make a best guess. So I see two paths... either you use a "Decode it for me according to content-type" interface, or a "Treat is as this type, and fail predictably if it's not" one. The current GET/POST is, of course, the latter. And there's no reason we can't have both :) -- Curtis On 5 September 2013 04:06, Jonathan Slenders <[email protected]>wrote: > Would that mean that the object returned by request.DATA/POST/whatever > could be a different type, depending on what the user posted? > > I don't want to see code like: > > if isinstance(request.DATA, YamlObject): ... > elif isinstance(request.DATA, dict): ... > > although, I'm not sure how any view could handle any random content-type... > > > > Le mercredi 4 septembre 2013 13:57:29 UTC+2, Marc Tamlyn a écrit : >> >> 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 <[email protected]> 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.**HttpReque**st._load_post_and_**files()` >>>>>> there is explicit mention of two content type ('multipart/form-data' and >>>>>> 'application/x-www-form-**urlenc**oded'), 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/**dat**a/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.**a**jax/<http://api.jquery.com/jQuery.ajax/>(the >>>>>> only one using 'application/x-www-form- >>>>>> **urlenc**oded' 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-develop...@**googlegroups.com. >>> To post to this group, send email to django-d...@**googlegroups.com. >>> >>> Visit this group at >>> http://groups.google.com/**group/django-developers<http://groups.google.com/group/django-developers> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
