#DJANGO REST FRAMEWORK MIXINS UPDATE#
#DJANGO REST FRAMEWORK MIXINS FULL#

Note: Custom DRF actions will contain actions that aren't part of the DRF list of accepted actions (because they are custom actions you're creating), so when you call get_serializer_class from inside your action method, it will return whatever your 'default' serializer class is. If we needed to make even more granular decisions about the serializer returned (maybe we want to use a more limited serializer for a list request and one with more data in a retrieve request), then our viewset can override get_write_serializer_class() to add that logic. This means that when a call is made to the API that uses MyModelViewSet, the get_serializer_class() method from ReadWriteSerializerMixin will automatically be called and will decide, based on the kind of API request being made, which serializer to use. Now the viewset MyModelViewSet has access to the attributes and methods from the mixin ReadWriteSerializerMixin. all () read_serializer_class = ModelReadSerializer write_serializer_class = ModelWriteSerializer serializers import ModelReadSerializer, ModelWriteSerializer class MyModelViewSet ( ReadWriteSerializerMixin, viewsets. mixins import ReadWriteSerializerMixin from.

The mixin gets used in a viewset like this:įrom rest_framework import viewsets from. For the 'update' actions to the API, it returns write_serializer_class otherwise it returns read_serializer_class. The get_serializer_class method makes the final decision on which serializer to use. The get_*_serializer_class() methods will raise an AssertionError if your viewset hasn't set the appropriate attribute or overridden the necessary method. Each attribute has a corresponding method to catch the error where the mixin is being used, but those attributes haven't been set. This mixin defines two new attributes, read_serializer_class and write_serializer_class. write_serializer_class is not None, ( '' %s ' should either include a `write_serializer_class` attribute,' 'or override the `get_write_serializer_class()` method.' % self. read_serializer_class def get_write_serializer_class ( self ): assert self. read_serializer_class is not None, ( '' %s ' should either include a `read_serializer_class` attribute,' 'or override the `get_read_serializer_class()` method.' % self. get_read_serializer_class () def get_read_serializer_class ( self ): assert self. get_write_serializer_class () return self.

''' read_serializer_class = None write_serializer_class = None def get_serializer_class ( self ): if self. Set read_serializer_class and write_serializer_class attributes on a viewset. It's not very useful on its own, but when it's inherited into a class, that class has access to the mixin's special attributes and methods.Ĭlass ReadWriteSerializerMixin ( object ): ''' Overrides get_serializer_class to choose the read serializer for GET requests and the write serializer for POST requests.

#DJANGO REST FRAMEWORK MIXINS FULL#

(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.

#DJANGO REST FRAMEWORK MIXINS UPDATE#

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.

Django rest framework mixins