Architecture scenarioMedium~10 minData & APIs / 5 of 33

Interview question

How would you design request DTOs for an HTTP endpoint, and why not bind directly to domain or persistence entities?

Design request DTOs for API boundaries

Design request DTOs that protect API contracts from domain and persistence models.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A request DTO defines exactly what the client may send for one operation. It is part of the API contract, while domain and persistence models are internal. Binding directly to a persistence model can expose fields the client should not control. A dedicated request model also gives validation and compatibility decisions an explicit boundary.

Full answer below

Practice focus

API boundary design, over-posting risk, validation ownership, DTO mapping, and compatibility

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.
Why this question matters
A request DTO is an operation-specific allowlist of client-controlled data. It protects domain and persistence models from becoming accidental public write contracts.
A request DTO defines exactly what the client may send for one operation. It is part of the API contract, while domain and persistence models are internal. Binding directly to a persistence model can expose fields the client should not control. A dedicated request model also gives validation and compatibility decisions an explicit boundary.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a create-user request might contain email and display name, while the stored entity also has identity, password hash, creation time, tenant, and role fields. Those are server-owned. The trade-off is mapping code, but the mapping makes ownership visible and prevents a persistence refactor from silently changing the public write contract. For public or sensitive operations, that explicitness is worth more than binding convenience.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use separate create, replace, and patch inputs because they have different absence and ownership semantics. Identity, audit, tenant, role, price, and workflow-state fields never become writable merely because they exist on an internal model. Mapping is also a review point for normalization and authorization-sensitive choices. I evolve request contracts additively where possible and protect them with contract tests. For partial updates I represent omitted versus explicit null deliberately instead of relying on language defaults or one large reusable DTO.

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

Binding directly to persistence entities
Using one DTO for create/update/response/internal commands
Letting clients send server-owned fields
Treating mapping as wasted work
Creating generic DTOs that hide intent

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Does not know over-posting risk
Cannot explain contract stability
Confuses DTOs with domain models
Only talks about AutoMapper

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What fields should never appear in a create request?
How would DTOs affect versioning?
When is direct binding acceptable?
Where would validation live?

Continue the section

Next in Data & APIs: Validation Strategy

Step 6 of 33

Design a validation strategy for ASP.NET Core APIs

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Skill areas

API Design Backend APIs

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Architecture scenarioMedium~10 minData & APIs / 5 of 33

Interview question

How would you design request DTOs for an HTTP endpoint, and why not bind directly to domain or persistence entities?

Design request DTOs for API boundaries

Design request DTOs that protect API contracts from domain and persistence models.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

API boundary design, over-posting risk, validation ownership, DTO mapping, and compatibility

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.
Why this question matters
A request DTO is an operation-specific allowlist of client-controlled data. It protects domain and persistence models from becoming accidental public write contracts.
A request DTO defines exactly what the client may send for one operation. It is part of the API contract, while domain and persistence models are internal. Binding directly to a persistence model can expose fields the client should not control. A dedicated request model also gives validation and compatibility decisions an explicit boundary.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a create-user request might contain email and display name, while the stored entity also has identity, password hash, creation time, tenant, and role fields. Those are server-owned. The trade-off is mapping code, but the mapping makes ownership visible and prevents a persistence refactor from silently changing the public write contract. For public or sensitive operations, that explicitness is worth more than binding convenience.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use separate create, replace, and patch inputs because they have different absence and ownership semantics. Identity, audit, tenant, role, price, and workflow-state fields never become writable merely because they exist on an internal model. Mapping is also a review point for normalization and authorization-sensitive choices. I evolve request contracts additively where possible and protect them with contract tests. For partial updates I represent omitted versus explicit null deliberately instead of relying on language defaults or one large reusable DTO.

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

Binding directly to persistence entities
Using one DTO for create/update/response/internal commands
Letting clients send server-owned fields
Treating mapping as wasted work
Creating generic DTOs that hide intent

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Does not know over-posting risk
Cannot explain contract stability
Confuses DTOs with domain models
Only talks about AutoMapper

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What fields should never appear in a create request?
How would DTOs affect versioning?
When is direct binding acceptable?
Where would validation live?

Continue the section

Next in Data & APIs: Validation Strategy

Step 6 of 33

Design a validation strategy for ASP.NET Core APIs

How would you design request DTOs for an HTTP endpoint, and why not bind directly to domain or persistence entities?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you design request DTOs for an HTTP endpoint, and why not bind directly to domain or persistence entities?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section