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})/ -- 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.
