Open lnielsen opened 8 years ago
@lnielsen can you provide an example how do you want to change the serializer API?
there are any news about this proposal?
Proposal is still valid and I think should be fixed prior to final release. For both proposal A and B, we need to check all uses of ContentNegotiatedMethodView
in other modules.
I would probably go with proposal A which involves:
dispatch_request
. ContentNegotiatedMethodView
to always call self.make_response
(this is usually what happens - see e.g. Records-REST and Files-REST).
Problem:
When you define a view method in a subclass of
ContentNegotiatedMethodView
you can currently return (retval
):make_response()
)make_response(*retval)
make_response(retval)
See here
This causes confusion with Flask's
make_response
which behaves differently, and it also makes it hard to 1) get a consistent API for serialisers over many modules 2) change simple things like e.g. response code while keeping the serialiser the same.Example: GET/POST serialisation of an object is likely the same, but often response code will be 200 vs 201/202.
Proposals
make_response()
explicitly from viewsmake_response()
and allow either 1) a response (already possible today) or 2) a 2/3-tuple of (response, status, headers) or (response, headers)