On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney <cur...@acommoncreative.com> wrote: > > On 9 September 2013 19:50, S Berder <sber...@gmail.com> 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.
