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
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
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
> 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
Hi Christopher,
On Tue, Sep 3, 2013 at 9:25 PM, Christopher Medrela wrote:
> 1. Progress: I've made improvements to admin checks. I've also finished
> implementing filtering and silencing checks. I've rebased my branch against
> master again.
>
> Excellent - I'll take
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
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