Why advanced DRF features matter in Django - Challenge Your Understanding

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this DRF serializer with nested relationships?

Given this Django REST Framework serializer code, what will be the JSON output when serializing a Book instance with one Author?

Django

from rest_framework import serializers

class AuthorSerializer(serializers.Serializer):
    name = serializers.CharField()

class BookSerializer(serializers.Serializer):
    title = serializers.CharField()
    author = AuthorSerializer()

book_data = {'title': 'Deep Learning', 'author': {'name': 'Ian Goodfellow'}}
serializer = BookSerializer(data=book_data)
serializer.is_valid()
print(serializer.data)

A {'title': 'Deep Learning', 'author': {'name': 'Ian Goodfellow'}}

B {'title': 'Deep Learning', 'author': 'Ian Goodfellow'}

C {'title': 'Deep Learning', 'author': None}

D Raises a TypeError

💡 Hint

Think about how nested serializers represent related objects in DRF.

The nested serializer AuthorSerializer correctly serializes the author field as a dictionary with the author's name. So the output includes the nested dictionary.

❓ state_output

intermediate

What is the value of validated_data after calling is_valid()?

Consider this DRF serializer with a custom validation method. What will serializer.validated_data contain after serializer.is_valid() is called?

Django

from rest_framework import serializers

class ProductSerializer(serializers.Serializer):
    name = serializers.CharField()
    price = serializers.FloatField()

    def validate_price(self, value):
        if value <= 0:
            raise serializers.ValidationError('Price must be positive')
        return value

input_data = {'name': 'Laptop', 'price': 999.99}
serializer = ProductSerializer(data=input_data)
serializer.is_valid()
print(serializer.validated_data)

A Raises ValidationError

B {'name': 'Laptop', 'price': '999.99'}

C {'name': 'Laptop', 'price': 999.99}

D {}

💡 Hint

Validated data converts fields to correct types and applies validations.

The price is positive, so validation passes and validated_data contains the input with correct types.

📝 Syntax

advanced

Which option correctly defines a DRF viewset with a custom action?

You want to add a custom action named highlight to a DRF viewset that responds to GET requests. Which code snippet is correct?

Django

from rest_framework import viewsets
from rest_framework.decorators import action
from rest_framework.response import Response

class ArticleViewSet(viewsets.ModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

    # Custom action here

A

@action(detail=False, methods=['post'])
def highlight(self, request):
    return Response({'highlighted': 'none'})

B

@action(detail=True, methods=['get'])
def highlight(self, request, pk=None):
    article = self.get_object()
    return Response({'highlighted': article.title.upper()})

C

@action(methods=['get'])
def highlight(self, request, pk=None):
    return Response({'highlighted': 'yes'})

D

@action(detail=True)
def highlight(self, request):
    return Response({'highlighted': 'no'})

💡 Hint

Custom actions need the detail and methods parameters correctly set.

Option B correctly uses @action with detail=True and methods=['get'], matching the requirement.

🔧 Debug

advanced

What error does this DRF serializer raise?

This serializer tries to use a field that does not exist on the model. What error will it raise when instantiated?

Django

from rest_framework import serializers

class UserSerializer(serializers.ModelSerializer):
    full_name = serializers.CharField()

    class Meta:
        model = User
        fields = ['username', 'email', 'full_name']

serializer = UserSerializer()

A Raises TypeError due to missing argument

B Raises AssertionError about missing field on model

C No error, serializer works fine

D Raises ValidationError at runtime

💡 Hint

ModelSerializer requires an instance or data argument when instantiated.

Instantiating a ModelSerializer without instance or data raises TypeError about missing required positional argument.

🧠 Conceptual

expert

Why use advanced DRF features like throttling and pagination?

Which of the following best explains why advanced DRF features such as throttling and pagination are important in real-world APIs?

A They automatically generate frontend UI components for the API.

B They simplify the code by removing the need for serializers.

C They replace the need for database indexing and caching.

D They improve API security and performance by limiting request rates and data size per response.

💡 Hint

Think about how APIs handle many users and large data sets.

Throttling controls how often clients can make requests, preventing overload. Pagination limits data size per response, improving speed and usability.

Practice

1. Why is it important to use advanced features like permissions in Django REST Framework (DRF)?

easy

A. To control who can access or modify API data

B. To speed up the server hardware

C. To change the database schema automatically

D. To make the API look prettier on the frontend

Solution

1. Step 1: Understand the role of permissions in DRF

   Permissions restrict or allow access to API endpoints based on user roles or authentication.

2. Step 2: Identify the purpose of permissions

   Permissions help keep data safe by controlling who can read or change it.

3. Final Answer:

   To control who can access or modify API data -> Option A

4. Quick Check:

   Permissions = Control access [OK]

Hint: Permissions control access rights in APIs [OK]

Common Mistakes:

• Thinking permissions improve server speed
• Confusing permissions with database changes
• Assuming permissions affect frontend design

2. Which of the following is the correct way to add pagination in a DRF viewset?

easy

A. pagination_class = PageNumberPagination

B. paginate = True

C. pagination = 'enabled'

D. page_size = 10

Solution

1. Step 1: Recall DRF pagination syntax

   DRF uses the attribute pagination_class to set pagination behavior in viewsets.

2. Step 2: Match the correct attribute and value

   Assigning PageNumberPagination to pagination_class enables page-based pagination.

3. Final Answer:

   pagination_class = PageNumberPagination -> Option A

4. Quick Check:

   Pagination uses pagination_class = PageNumberPagination [OK]

Hint: Use pagination_class to enable pagination in DRF [OK]

Common Mistakes:

• Using incorrect attribute names like paginate or pagination
• Setting page_size without pagination_class
• Assigning string values instead of classes

3. Given this DRF serializer method:

class MySerializer(serializers.ModelSerializer):
    def create(self, validated_data):
        user = self.context['request'].user
        validated_data['owner'] = user
        return super().create(validated_data)

What does this method do when creating an object?

medium

A. It raises an error because 'owner' is not in validated_data

B. It ignores the user and creates an anonymous object

C. It assigns the current user as the owner of the new object

D. It deletes the user from the request context

Solution

1. Step 1: Analyze the create method override

   The method adds the current user from the request context to the validated data under 'owner'.

2. Step 2: Understand the effect on object creation

   By adding 'owner', the created object will link to the user who made the request.

3. Final Answer:

   It assigns the current user as the owner of the new object -> Option C

4. Quick Check:

   create() adds user as owner [OK]

Hint: create() can add user info from context automatically [OK]

Common Mistakes:

• Assuming it raises error if 'owner' missing
• Thinking it deletes user from context
• Believing it ignores user data

4. You have this DRF viewset snippet:

class MyViewSet(viewsets.ModelViewSet):
    queryset = MyModel.objects.all()
    serializer_class = MySerializer
    permission_classes = [IsAuthenticated]

    def get_queryset(self):
        return MyModel.objects.filter(owner=self.request.user)

What is the main issue with this code?

medium

A. serializer_class must be a list, not a single class

B. permission_classes should be a tuple, not a list

C. get_queryset should not filter by owner

D. The queryset attribute is overridden by get_queryset, so it is redundant

Solution

1. Step 1: Understand get_queryset overriding

   Defining get_queryset replaces the queryset attribute for filtering dynamically.

2. Step 2: Identify redundancy

   Since get_queryset returns a filtered queryset, the class-level queryset is not used and is redundant.

3. Final Answer:

   The queryset attribute is overridden by get_queryset, so it is redundant -> Option D

4. Quick Check:

   get_queryset overrides queryset attribute [OK]

Hint: get_queryset overrides queryset attribute in viewsets [OK]

Common Mistakes:

• Thinking permission_classes must be a tuple
• Believing filtering by owner is wrong here
• Assuming serializer_class must be a list

5. You want to create a DRF API that returns a paginated list of items owned by the logged-in user, and automatically assigns the user as owner when creating new items. Which combination of features should you use?

hard

A. Use pagination_class only, without filtering or permissions

B. Use permission_classes to require login, override get_queryset to filter by user, use pagination_class, and override serializer create() to set owner

C. Use permission_classes to allow all, override get_queryset to return all items, and do not override create()

D. Use no permissions, set queryset to all items, disable pagination, and set owner manually in frontend

Solution

1. Step 1: Identify security and filtering needs

   Require login with permission_classes and filter queryset by logged-in user to show only their items.

2. Step 2: Add pagination and automatic owner assignment

   Use pagination_class to handle large data sets and override serializer create() to assign owner automatically.

3. Final Answer:

   Use permission_classes to require login, override get_queryset to filter by user, use pagination_class, and override serializer create() to set owner -> Option B

4. Quick Check:

   Permissions + filtering + pagination + create() override = D [OK]

Hint: Combine permissions, filtering, pagination, and create() override [OK]

Common Mistakes:

• Ignoring permissions and filtering
• Not using pagination for large data
• Setting owner only on frontend