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. For more options, visit https://groups.google.com/groups/opt_out.
