(The full list of API actions is in the DRF codebase.) But we wound up repeating ourselves across several viewsets, so we wrote a mixin to take care of some of this work for us!Ī mixin is a Python class that contains custom attributes and methods ( more explanation).
We returned the "read" serializer for list and retrieve actions, and the "update" serializer for everything else. The first way we approached using different serializers for read and update actions was to override get_serializer_class() on each viewset to decide which serializer to return depending on the action in the request. The requests to update data via the API, though, didn't need these expanded fields. In our case, this was because the GET serializer contained a lot of nested data for example, it contained expanded fields from other serializers to foreign-key relationships. POST/PUT/PATCH requests to our Django REST Framework API. On a recent project, we needed to use different serializers for GET vs.
0 kommentar(er)
