What belongs in DRF serializer validation, and what belongs in application logic?

Keeps representation validation at the API boundary and moves changing workflows to explicit application owners.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Serializer fields and validators are good for type, format, required values, and cross-field consistency in the submitted representation. Business logic that depends on authorization, changing database state, several models, external services, or transaction ownership belongs in an explicit application workflow. The view supplies trusted request context and calls that workflow after the serializer has validated the transport input.

Full answer below

Practice focus

Judgment about deterministic input rules, authorization, database facts, external I/O, and orchestration.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
Serializer validation should answer whether an input representation is acceptable, not secretly run the whole use case.
Serializer fields and validators are good for type, format, required values, and cross-field consistency in the submitted representation. Business logic that depends on authorization, changing database state, several models, external services, or transaction ownership belongs in an explicit application workflow. The view supplies trusted request context and calls that workflow after the serializer has validated the transport input.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A database lookup in validation can improve an error message, but it is not a concurrency guarantee and should not become the only enforcement of an invariant. I avoid validators with external side effects because validation may be called more than once and callers expect it to be safe. create() and can map validated data to persistence, but complex orchestration should be named and tested outside the serializer.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Performing external side effects inside validate().
Treating a pre-write uniqueness query as an integrity guarantee.
Making application services raise DRF response exceptions directly.

What belongs in DRF serializer validation, and what belongs in application logic?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?