Closed GasparPizarro closed 7 years ago
Yes, that is as designed.
Since DRF uses a serializer on POST requests to deserialize and validate (when creating an instance), and it also uses a serializer to return a representation of the created instance, there would be ambiguity here on which serializer the fields should apply to. Any effects for POST requests are explicitly disabled and fields=
is ignored.
If you have heavy fields you don't want serialized it might be better to exclude those all the time in the response to POST. You can do that in DRF directly, we don't need queryfields for that. But if the fields returned in a newly created instance need to be customized by the client on a per-request basis, then maybe I can extend queryfields to support this behaviour - please clarify the use case required?
I'm gonna go with the serializer.fields.pop
approach now. Thanks.
I have an APIView with get, post, and patch methods. and I am returning data through a QueryFieldsMixin-inherited serializer, passing the request as context, like this:
[GET] return Response(ThingSerializer(analyses, many=True, context={'request': request}).data)
[POST] return Response(AnalysisSerializer(analysis, context={'request': request}).data, status=status.HTTP_201_CREATED)
[PATCH] return Response(AnalysisSerializer(analysis, context={'request': request}).data)
However, the
fields=
andfields!=
only work with the GET requests. In the other cases, the full object, which has a very heavy field that I must not return, is returned. Is this expected behavior?