Re: Support POST of application/json content type

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 https://groups.google.com/forum/#!topic/django-rest-fram

Re: Support POST of application/json content type

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 ticket_2144

Re: Support POST of application/json content type

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 resul

Re: Support POST of application/json content type

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 thi

Re: Support POST of application/json content type

> 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 s

Re: Support POST of application/json content type

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 see the >>> implementation of a response/request encode/decode framew

Re: Support POST of application/json content type

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: >> >> * need a pluggable interface so current content-ty

Re: Support POST of application/json content type

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 > (`application/x-www-form-urlencoded`, `multipar

Re: Support POST of application/json content type

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 an

Re: Support POST of application/json content type

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 r

Re: Support POST of application/json content type

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

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 han

Re: Support POST of application/json content type

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 ava

Re: Support POST of application/json content type

> 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 whatev

Re: Support POST of application/json content type

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 t

Re: Support POST of application/json content type

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 commente

Re: Support POST of application/json content type

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 handling > request content types?

Re: Support POST of application/json content type

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 existi

Re: Support POST of application/json content type

+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 att