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 thing
to do". I think it would make for a stronger interface of you could simply
find your data in request.data.
I will create a branch in my fork on github and will send it here for
progress.
Stefan, from my mobile
--
http://www.bonz.org/
/(bb|[^b]{2}/
On 12 Sep 2013 18:20, "Tom Christie" wrote:
> > 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 start
> supporting JSON or other data without any other changes required.
> * Form expect the data and files to be provided separately which would be
> awkward otherwise.
>
> > In the absence of strong objection, I will start working on this base.
>
> Sure thing. As it happens, I was also considering taking a crack at this
> in the coming weeks, so please do follow up on this thread linking to your
> repo if you start working on it, so myself and others can track any
> progress. (And perhaps collaborate.)
>
> Cheers :)
>
> Tom
>
> On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>>
>> 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 framework:
>> >>>
>> >>> * need a pluggable interface so current content-types are supported
>> >>> (`application/x-www-form-**urlencoded`, `multipart/form-data`), new
>> >>> types (`application/json`), custom and future types
>> >>> (`application/vnd.foobar+json` anybody? See
>> >>> http://developer.github.com/**v3/media/#api-v3-media-type-**
>> and-the-future<http://developer.github.com/v3/media/#api-v3-media-type-and-the-future>
>> >>> for example, `application/msgpack`, `application/protobuf`,
>> >>> `application/capnproto`, etc).
>> >>> * decoder/encoder map (content-type, decoder) should be smart to
>> >>> handle patterns like `text/*` or `application/*xml*` and match things
>> >>> like `Accept: application/json, text/plain, * / *`
>> >>> * choice of decoder would be made on the Content-Type header, maybe
>> >>> supporting a raw by default so data is just passed in case of unknown
>> >>> content type.
>> >>> * decoder/encoder should be available through `request` and
>> `response`
>> >>> objects.
>> >>> * decoded data structure (python object) would be stored in
>> `request.data`
>> >>> * first step is to support requests, next step is to handle responses
>> >>> with the same pluggable functionality and coherent API.
>> >>> * A sensible default for response Content-type would be `text/html;
>> >>> charset=UTF-8`. It should be made available through a setting entry
>> >>> anyway
>> >>>
>> >>
>> >> You should also have access to the decision made by the data parser as
>> to
>> >> which parser was used, instead of having to infer it yourself from the
>> >> content type header.
>> >
>> > Indeed, that's the 4th point of my list, maybe it's not clear as it is
>> > but this would be supported.
>> >
>> >>>
>> >>> Some questions though:
>> >>>
>> >>> * why keep data and files separated, I see no good reason for this
>> >>> except mimicking PHP's structure. An uploaded file comes from a named
>> >>> input, I hope to find it in request.data (why do a common structure
>> >>> otherwise). I might be missing something but nothing indicates a real
>> >>> need for this in django/http/request.py
>> >>
>> >>
>> >> True, there's some added complexity [small as it is] in forms because
>> File
>> >> fields need to look els
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 framework:
>>>
>>> * need a pluggable interface so current content-types are supported
>>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new
>>> types (`application/json`), custom and future types
>>> (`application/vnd.foobar+json` anybody? See
>>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
>>> for example, `application/msgpack`, `application/protobuf`,
>>> `application/capnproto`, etc).
>>> * decoder/encoder map (content-type, decoder) should be smart to
>>> handle patterns like `text/*` or `application/*xml*` and match things
>>> like `Accept: application/json, text/plain, * / *`
>>> * choice of decoder would be made on the Content-Type header, maybe
>>> supporting a raw by default so data is just passed in case of unknown
>>> content type.
>>> * decoder/encoder should be available through `request` and `response`
>>> objects.
>>> * decoded data structure (python object) would be stored in `request.data`
>>> * first step is to support requests, next step is to handle responses
>>> with the same pluggable functionality and coherent API.
>>> * A sensible default for response Content-type would be `text/html;
>>> charset=UTF-8`. It should be made available through a setting entry
>>> anyway
>>>
>>
>> You should also have access to the decision made by the data parser as to
>> which parser was used, instead of having to infer it yourself from the
>> content type header.
>
> Indeed, that's the 4th point of my list, maybe it's not clear as it is
> but this would be supported.
>
>>>
>>> Some questions though:
>>>
>>> * why keep data and files separated, I see no good reason for this
>>> except mimicking PHP's structure. An uploaded file comes from a named
>>> input, I hope to find it in request.data (why do a common structure
>>> otherwise). I might be missing something but nothing indicates a real
>>> need for this in django/http/request.py
>>
>>
>> True, there's some added complexity [small as it is] in forms because File
>> fields need to look elsewhere for their values.
>>
>>>
>>> * isn't more or less any data sent to your backend representable as a
>>> dict or object with dict access modes? I try to think about
>>> occurrences where some data would not have a 'name'.
>>>
>>
>> I frequently send JSON lists of data to my APIs...
> Ok, was a bit short sighted on this one, still thinking in terms of
> form bound data, it was a long day here in Shanghai. I suppose that
> the kind of python object you receive is not so important as you
> should do data validation anyway. Your earlier concern about checking
> for different content-types doesn't apply to the solution I have in
> mind as to whatever data representation you have at the beginning, you
> should get a very similar object after decoding. What I mean is if you
> send the *same* data through Yaml or JSON, the object in request.data
> should be the same or extremely close. I say extremely close because
> I'm thinking about xml that is always way more verbose than the others
> and *might* add more data to the resulting object. (hint: I don't like
> XML, don't need it in what I do and last used it ~8/9 years ago in a
> disastrous explosion of SOAP and unix/microsoft interfaces)
>
> Stefan
> --
> http://www.bonz.org/
> /(bb|[^b]{2})/
In the absence of strong objection, I will start working on this base.
Stefan
--
http://www.bonz.org/
/(bb|[^b]{2})/
--
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.
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-types are supported
>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new
>> types (`application/json`), custom and future types
>> (`application/vnd.foobar+json` anybody? See
>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
>> for example, `application/msgpack`, `application/protobuf`,
>> `application/capnproto`, etc).
>> * decoder/encoder map (content-type, decoder) should be smart to
>> handle patterns like `text/*` or `application/*xml*` and match things
>> like `Accept: application/json, text/plain, * / *`
>> * choice of decoder would be made on the Content-Type header, maybe
>> supporting a raw by default so data is just passed in case of unknown
>> content type.
>> * decoder/encoder should be available through `request` and `response`
>> objects.
>> * decoded data structure (python object) would be stored in `request.data`
>> * first step is to support requests, next step is to handle responses
>> with the same pluggable functionality and coherent API.
>> * A sensible default for response Content-type would be `text/html;
>> charset=UTF-8`. It should be made available through a setting entry
>> anyway
>>
>
> You should also have access to the decision made by the data parser as to
> which parser was used, instead of having to infer it yourself from the
> content type header.
Indeed, that's the 4th point of my list, maybe it's not clear as it is
but this would be supported.
>>
>> Some questions though:
>>
>> * why keep data and files separated, I see no good reason for this
>> except mimicking PHP's structure. An uploaded file comes from a named
>> input, I hope to find it in request.data (why do a common structure
>> otherwise). I might be missing something but nothing indicates a real
>> need for this in django/http/request.py
>
>
> True, there's some added complexity [small as it is] in forms because File
> fields need to look elsewhere for their values.
>
>>
>> * isn't more or less any data sent to your backend representable as a
>> dict or object with dict access modes? I try to think about
>> occurrences where some data would not have a 'name'.
>>
>
> I frequently send JSON lists of data to my APIs...
Ok, was a bit short sighted on this one, still thinking in terms of
form bound data, it was a long day here in Shanghai. I suppose that
the kind of python object you receive is not so important as you
should do data validation anyway. Your earlier concern about checking
for different content-types doesn't apply to the solution I have in
mind as to whatever data representation you have at the beginning, you
should get a very similar object after decoding. What I mean is if you
send the *same* data through Yaml or JSON, the object in request.data
should be the same or extremely close. I say extremely close because
I'm thinking about xml that is always way more verbose than the others
and *might* add more data to the resulting object. (hint: I don't like
XML, don't need it in what I do and last used it ~8/9 years ago in a
disastrous explosion of SOAP and unix/microsoft interfaces)
Stefan
--
http://www.bonz.org/
/(bb|[^b]{2})/
--
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.
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 and future types (`application/vnd.foobar+json` anybody? See http://developer.github.com/v3/media/#api-v3-media-type-and-the-future for example, `application/msgpack`, `application/protobuf`, `application/capnproto`, etc). * decoder/encoder map (content-type, decoder) should be smart to handle patterns like `text/*` or `application/*xml*` and match things like `Accept: application/json, text/plain, * / *` * choice of decoder would be made on the Content-Type header, maybe supporting a raw by default so data is just passed in case of unknown content type. * decoder/encoder should be available through `request` and `response` objects. * decoded data structure (python object) would be stored in `request.data` * first step is to support requests, next step is to handle responses with the same pluggable functionality and coherent API. * A sensible default for response Content-type would be `text/html; charset=UTF-8`. It should be made available through a setting entry anyway Some questions though: * why keep data and files separated, I see no good reason for this except mimicking PHP's structure. An uploaded file comes from a named input, I hope to find it in request.data (why do a common structure otherwise). I might be missing something but nothing indicates a real need for this in django/http/request.py * isn't more or less any data sent to your backend representable as a dict or object with dict access modes? I try to think about occurrences where some data would not have a 'name'. I'm sure I left some obvious things out like more settings and others but this will become obvious while coding. If no strong objection, I'm ready to start in that direction and provide code sometime next week. Stefan On Thu, Sep 5, 2013 at 7:31 AM, Curtis Maloney wrote: > 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 > 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 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
