DRF Views

Key features

• APIView.dispatch() is what actually runs DRF's authentication/permission/throttle checks before calling get()/post()/etc. — a plain Django View subclass calling these methods manually would skip that machinery entirely
• request.data (not request.POST) is DRF's parsed-body access on an APIView — it works for JSON, form data, and multipart alike, unlike request.POST, which only handles form-encoded/multipart bodies
• Each generic view mixes GenericAPIView (queryset/serializer_class handling, pagination hooks, filtering hooks) with one or more of the five model mixins — ListAPIView = ListModelMixin + GenericAPIView with get() calling self.list()
• ListCreateAPIView and RetrieveUpdateDestroyAPIView are the two most commonly used COMBINED generic views — list+create on a collection endpoint, retrieve+update+delete on a detail endpoint, matching the conventional URL pattern of /items/ vs /items/<pk>/
• Each mixin method (list(), create(), retrieve(), update(), destroy()) internally calls get_queryset()/get_object()/get_serializer() — overriding one of THOSE hook methods is usually the correct way to customize behavior, rather than overriding list()/create() themselves
• UpdateModelMixin.update() handles both PUT (full update) and PATCH (partial update, via partial=True passed to the serializer) through the same method — partial is determined from the request method, not a separate mixin

Command

class MyView(generics.ListCreateAPIView):
    queryset = Model.objects.all()
    serializer_class = MySerializer

Key features

• ViewSet action names are list/create/retrieve/update/partial_update/destroy — not get/post/put/patch/delete; a Router maps HTTP methods to these action names according to a fixed, documented convention
• GenericViewSet provides queryset/serializer_class/get_object()/etc. but implements ZERO actions on its own — it must be combined with mixins (like a generic view built from scratch) to do anything
• ModelViewSet = GenericViewSet + all five model mixins — the single-class equivalent of ListCreateAPIView + RetrieveUpdateDestroyAPIView combined, for the common "full CRUD on one resource" case
• router.register(prefix, viewset, basename) adds a ViewSet's auto-generated URLs under prefix — DefaultRouter additionally generates a browsable API root view listing every registered ViewSet, SimpleRouter does not
• @action(detail=True, methods=["post"]) creates a URL nested under a specific object (/articles/5/publish/); detail=False creates one under the collection (/articles/recent/) — both still go through the same ViewSet's permission/authentication setup
• A ViewSet not registered with a Router has no automatic URLs at all — it can still be used with .as_view({"get": "list"}) manually mapping HTTP methods to actions, which is how a ViewSet can be wired into a plain urls.py path() when a Router's conventions don't fit

Command

class MyViewSet(viewsets.ModelViewSet):
    queryset = Model.objects.all()
    serializer_class = MySerializer

    @action(detail=True, methods=["post"])
    def custom_action(self, request, pk=None):
        ...

Key features

• get_queryset() is called by every mixin method (list(), retrieve(), update(), destroy()) that needs a queryset — overriding it centralizes per-request filtering in ONE place rather than repeating it per action
• get_serializer_class() defaults to returning self.serializer_class — override it to switch serializers by self.action (on a ViewSet) or self.request.method, e.g. a lighter serializer for list than for retrieve
• get_serializer() is what actually calls get_serializer_class() to get a class, then instantiates it with get_serializer_context() merged in — call THIS (not the serializer class directly) inside a custom action to stay consistent with the view's own configuration
• get_serializer_context() by default returns {"request": self.request, "view": self, "format": self.format_kwarg} — override to add project-specific context, calling super() first to keep the defaults
• perform_create(serializer) defaults to serializer.save() — override to pass extra kwargs (perform_create(serializer): serializer.save(owner=self.request.user)) or add a side effect (queuing a task) around the save
• perform_update()/perform_destroy() follow the same pattern as perform_create() — CreateModelMixin/UpdateModelMixin/DestroyModelMixin call the perform_*() hook specifically so response-building logic (status code, serialized output) never needs to be touched just to add a side effect around the actual save/delete

Command

def get_queryset(self):
    return super().get_queryset().filter(...)

def perform_create(self, serializer):
    serializer.save(extra_field=...)