Re: Support POST of application/json content type

2014-05-05 Thread Dmitry Mugtasimov
It looks like there is a lot of work to do for full featured content-type support. Meanwhile if you need just to integrate Django + Django REST Framework and django-oauth-plus for PUT-parameters support, please, take a look at this thread

Re: Support POST of application/json content type

2013-11-18 Thread Tom Christie
I've created the ticket 21442 to track 'Configurable request parsing'. I've also made a first pass at refactoring the current request parsing into a generic interface that can support arbitrary parsers, and pushed the current status to the

Re: Support POST of application/json content type

2013-10-09 Thread abh2134
Hi all, I would love to be involved with this feature. My suggestion is to do the following: - Check requst.is_ajax() - Check request.META.get('CONTENT_TYPE').count('application/json') - Parse request.body using django.utils.simplejson.loads - ... and set *request.JSON* to the

Re: Support POST of application/json content type

2013-09-12 Thread S Berder
Tom, I get the context and that form is tied to that behavior but outside of "that's how it is now" is there any technical reason for this? I can't read forms code at the moment but will do tonight and will look at how FILES is used in there. I'm not usually afraid by impacts of it's the "right

Re: Support POST of application/json content type

2013-09-12 Thread Tom Christie
> why keep data and files separated Mostly because that's the way it already works, so... * request.data would essentially provide a strict superset of the functionality that request.POST provides. In general you'd be able to replace `request.POST` with `request.data` anywhere and seemlessly

Re: Support POST of application/json content type

2013-09-10 Thread S Berder
On Tue, Sep 10, 2013 at 12:17 PM, S Berder wrote: > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney > wrote: >> >> On 9 September 2013 19:50, S Berder wrote: >>> >>> Gents, >>> to sum it up, arguments made and details of how I

Re: Support POST of application/json content type

2013-09-09 Thread S Berder
On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney wrote: > > On 9 September 2013 19:50, S Berder wrote: >> >> Gents, >> to sum it up, arguments made and details of how I see the >> implementation of a response/request encode/decode framework: >> >> *

Re: Support POST of application/json content type

2013-09-09 Thread Curtis Maloney
On 9 September 2013 19:50, S Berder wrote: > Gents, > to sum it up, arguments made and details of how I see the > implementation of a response/request encode/decode framework: > > * need a pluggable interface so current content-types are supported >

Re: Support POST of application/json content type

2013-09-09 Thread S Berder
Gents, to sum it up, arguments made and details of how I see the implementation of a response/request encode/decode framework: * need a pluggable interface so current content-types are supported (`application/x-www-form-urlencoded`, `multipart/form-data`), new types (`application/json`), custom

Re: Support POST of application/json content type

2013-09-06 Thread Tom Christie
In REST framework, we expose the accepted renderer as an `request.accepted_renderer` property. This allows you to switch based on the media type when needed by either doing something like: if request.accepted_renderer.format == 'yaml': # do something specific or like this: if

Re: Support POST of application/json content type

2013-09-04 Thread Curtis Maloney
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

Re: Support POST of application/json content type

2013-09-04 Thread Jonathan Slenders
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

Re: Support POST of application/json content type

2013-09-04 Thread Marc Tamlyn
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

Re: Support POST of application/json content type

2013-09-04 Thread Tom Christie
> 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

Re: Support POST of application/json content type

2013-09-04 Thread Stefan Berder
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

Re: Support POST of application/json content type

2013-09-04 Thread Tom Christie
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

Re: Support POST of application/json content type

2013-09-03 Thread Curtis Maloney
Someone remind me never to post to list before I've had my second coffee? :) Of course the above would trivially be handled using middleware. -- C On 4 September 2013 10:05, Curtis Maloney wrote: > What do people think of an extensible registration approach to

Re: Support POST of application/json content type

2013-09-03 Thread Curtis Maloney
What do people think of an extensible registration approach to handling request content types? Something along the lines of ('POST', [list of content types], class to handle it) This would mean adding a request.JSON would be simple for the projects that want it, and even overriding how the

Re: Support POST of application/json content type

2013-09-03 Thread Marc Tamlyn
+1 to providing a better way of accessing JSON encoded post data. -1 to it being munged into request.POST - I feel this is unintuitive. A nice possibility could be a simple piece of middleware which detects `application/json` and attaches request.json as an attribute, if it can decode it. This

Support POST of application/json content type

2013-09-03 Thread Stefan Berder
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