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
<cur...@acommoncreative.com> 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 <jonathan.slend...@gmail.com>
> 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 <christ...@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, 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, see "Setting
>>>>>>> HTTP Headers"
>>>>>>> * emberjs:
>>>>>>> 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/ (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-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.
>>>> 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.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/s8OZ9yNh-8c/unsubscribe.
> To unsubscribe from this group and all its topics, 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.



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

Reply via email to