← Django REST Framework: practical APIs Progress & review ↗

Typorithm · medium

Serializer fields define the accepted value contract

pythondjangodrfindependent-practice

Saved on this device

Full lesson · 4 learning steps Open any exercise for focused practice

Step 1 of 4 · intro card

Serializer fields define the accepted value contract

Concept and contract

Separate missing, null, blank, coercion and public representation.

A serializer translates between external primitive values and validated application values. Parsing JSON does not establish that a title is nonblank or that a number of openings is positive. Declare those policies on the fields that own them.

RoleInput accepts a trimmed title and a bounded integer slots value. A numeric string may be normalized under IntegerField, while zero violates the declared lower bound. The inspection result exposes validated_data only after is_valid succeeds and otherwise returns stable field error codes.

Mechanism and worked example

CharField trims surrounding whitespace by default, checks blank input and applies the declared length.

CharField trims surrounding whitespace by default, checks blank input and applies the declared length. required describes omission, allow_null describes an explicit null and allow_blank describes empty text. They solve different problems and should not be interchanged casually.

IntegerField validates a positive small count here. The field contract is deliberately independent of any database model. The lab compares exact normalized values and verifies that caller input was not mutated. A valid serializer does not save anything unless an appropriate save path is implemented and called.

Complete worked example

python

from drf_lab import setup
setup()

from rest_framework import serializers

class RoleInput(serializers.Serializer):
    title = serializers.CharField(max_length=20)
    slots = serializers.IntegerField(min_value=1, max_value=3)

def inspect_example(payload):
    serializer = RoleInput(data=payload)
    if serializer.is_valid():
        return {"value": dict(serializer.validated_data)}
    return {"errors": {key: [error.code for error in errors]
                       for key, errors in serializer.errors.items()}}

Reasoning: CharField trims surrounding whitespace by default, checks blank input and applies the declared length. required describes omission, allow_null describes an explicit null and allow_blank describes empty text. They solve different problems and should not be interchanged casually. IntegerField validates a positive small count here. The field contract is deliberately independent of any database model. The lab compares exact normalized values and verifies that caller input was not mutated. A valid serializer does not save anything unless an appropriate save path is implemented and called.

Focused decision: context is in the complete example

python

class RoleInput(serializers.Serializer):
    title = serializers.CharField(max_length=20)
    slots = serializers.IntegerField(min_value=1, max_value=3)

serializer = RoleInput(data=payload)
if serializer.is_valid():
    accepted = serializer.validated_data

Focused decision: Reconstruct this focused decision after the warm-up. The complete imports, model or application, and test client remain in the worked example. Typing records practice; only the downloadable computer lab executes Python.

Counterexamples and common mistakes

The controlled mistake removes the positive minimum.

The controlled mistake removes the positive minimum. A zero count then becomes accepted under a different contract. A successful parse or a JSON numeric type cannot compensate for the missing application bound.

DRF also commonly ignores undeclared input fields rather than automatically implementing a forbid-extras policy. Do not import Pydantic assumptions into another framework. Use an explicit request policy when unexpected keys must be rejected, and never infer authorization from the fact that a serializer accepted a value.

Controlled mistake: observe the actual wrong behavior

python

from drf_lab import setup
setup()

from rest_framework import serializers

class RoleInput(serializers.Serializer):
    title = serializers.CharField(max_length=20)
    slots = serializers.IntegerField(max_value=3)

def inspect_example(payload):
    serializer = RoleInput(data=payload)
    if serializer.is_valid():
        return {"value": dict(serializer.validated_data)}
    return {"errors": {key: [error.code for error in errors]
                       for key, errors in serializer.errors.items()}}

Reasoning: The controlled mistake removes the positive minimum. A zero count then becomes accepted under a different contract. A successful parse or a JSON numeric type cannot compensate for the missing application bound. DRF also commonly ignores undeclared input fields rather than automatically implementing a forbid-extras policy. Do not import Pydantic assumptions into another framework. Use an explicit request policy when unexpected keys must be rejected, and never infer authorization from the fact that a serializer accepted a value.

Independent practice

Increase the maximum slots value from three to five.

Increase the maximum slots value from three to five. Preserve positive counts, title trimming and nonblank validation. The new task is one field-bound change, not an invitation to turn every value into an optional string.

Test five as accepted, six as rejected and a blank title as rejected. Predict which field owns each failure. Keep the existing imports and serializer structure; changing the helper output would not demonstrate that the validation policy itself changed.

Step 1: Allow up to five slots while retaining positive counts and nonblank trimmed titles. Step 2: Retain the working imports and application structure. Change the stated policy, run the supplied practice cases, then explain the newly accepted or rejected boundary.

Practice starter: solve before reading the solution

python

from drf_lab import setup
setup()

from rest_framework import serializers

class RoleInput(serializers.Serializer):
    title = serializers.CharField(max_length=20)
    slots = serializers.IntegerField(min_value=1, max_value=3)

def inspect_example(payload):
    serializer = RoleInput(data=payload)
    if serializer.is_valid():
        return {"value": dict(serializer.validated_data)}
    return {"errors": {key: [error.code for error in errors]
                       for key, errors in serializer.errors.items()}}

# Independent task: Allow up to five slots while retaining positive counts and nonblank trimmed titles.

Reasoning: Allow up to five slots while retaining positive counts and nonblank trimmed titles.

Hint 1: Find the one field or branch that owns this policy.
Hint 2: Compare the first changed acceptance case with the retained baseline.

Solution, tests and trade-offs

The solution changes max_value only.

The solution changes max_value only. It retains the positive minimum and title policy, and the new acceptance cases demonstrate the changed upper boundary without weakening the unrelated field. A numeric string still becomes a validated integer.

A real resource limit should also be enforced where the work is performed. Accepting at most five submitted openings does not bound a database scan or a downstream task count automatically. Distinguish the request representation from producer workload, storage constraints and access control.

Practice solution and acceptance checks

python

from drf_lab import setup
setup()

from rest_framework import serializers

class RoleInput(serializers.Serializer):
    title = serializers.CharField(max_length=20)
    slots = serializers.IntegerField(min_value=1, max_value=5)

def inspect_example(payload):
    serializer = RoleInput(data=payload)
    if serializer.is_valid():
        return {"value": dict(serializer.validated_data)}
    return {"errors": {key: [error.code for error in errors]
                       for key, errors in serializer.errors.items()}}

Reasoning: The solution changes max_value only. It retains the positive minimum and title policy, and the new acceptance cases demonstrate the changed upper boundary without weakening the unrelated field. A numeric string still becomes a validated integer. A real resource limit should also be enforced where the work is performed. Accepting at most five submitted openings does not bound a database scan or a downstream task count automatically. Distinguish the request representation from producer workload, storage constraints and access control.

Interview reasoning and next step

In an interview, contrast missing, null and blank with one example of each.

In an interview, contrast missing, null and blank with one example of each. Then explain why validated_data is appropriate after is_valid and why initial_data is still untrusted input. Use the zero-count counterexample to connect a declaration to observable behavior.

The next lesson adds object and list validation. Several individually valid fields may form an invalid combination, and current DRF reports list failures in a format that differs from older releases.

Optional stretch — after the core task works: Add one independently reasoned boundary case and explain its expected value before running it.

Computer practice: https://applydjinn.com/typorithm/drf-lab-20261105.zip. Install pinned dependencies in an isolated Python environment. Run verify.py, then change the working exercise baseline and run --practice drf-fields. The real DRF clients, serializers, schemas and SQLite transactions use owned fixtures only. No production database, feed, account or paid service is used. This lab executes Python; the PC typing trainer and native reading progress do not execute it.

Separate missing, null, blank, coercion and public representation.