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-framework/679fOg0QpzI and this post https://groups.google.com/d/msg/django-rest-framework/679fOg0QpzI/2qeQGdzq-FsJ in particular.
понедельник, 18 ноября 2013 г., 17:42:31 UTC+4 пользователь Tom Christie написал: > > I've created the ticket 21442<https://code.djangoproject.com/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_21442 > branch<https://github.com/tomchristie/django/tree/ticket_21442>on my GitHub > account. > > It's likely that the API will need a few design decisions along the way, > so I'd suggest anyone who's interested in contributing to this work makes > sure to follow the ongoing work in that branch. > > Cheers all, > > Tom > > On Thursday, 12 September 2013 11:20:07 UTC+1, 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 <[email protected]> wrote: >>> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney >>> > <[email protected]> wrote: >>> >> >>> >> On 9 September 2013 19:50, S Berder <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16b1d8d2-c22b-486b-8107-11fa672553a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
