Concept questionEasy~5 min

Interview question

What does `[ApiController]` change for an ASP.NET Core controller, especially around routing, binding, and validation errors?

ApiController conventions and automatic validation responses

Explains attribute routing, binding-source inference, automatic validation responses, and where explicit domain validation still belongs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

[ApiController] enables API-focused controller conventions. It requires attribute routing, infers common binding sources, and automatically returns a 400 response when binding or input validation leaves ModelState invalid. That removes routine ModelState checks, but it does not replace business rules such as ownership, stock availability, or valid state transitions.

Full answer below

Practice focus

Controller conventions, automatic HTTP 400 responses, `ModelState`, `ValidationProblemDetails`, binding-source inference, and domain validation boundaries.

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
[ApiController] removes repetitive controller plumbing, but only when its conventions and limits are understood. Automatic request validation is not the same as validating a business operation.
[ApiController] enables API-focused controller conventions. It requires attribute routing, infers common binding sources, and automatically returns a 400 response when binding or input validation leaves ModelState invalid. That removes routine ModelState checks, but it does not replace business rules such as ownership, stock availability, or valid state transitions.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I still use an explicit request DTO and binding attributes when the public source would be ambiguous. The automatic 400 normally uses ValidationProblemDetails, so I keep that shape aligned with the rest of the API's error contract. If I suppress the automatic response or customize it, the application owns equivalent behavior and tests.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
These conventions are part of the wire contract. Changing nullability, validation attributes, JSON settings, or parameter binding can reject a request before the action runs. I distinguish malformed input from business conflicts and authorization failures instead of returning 400 for everything. A small set of real HTTP contract tests proves the status and problem shape at the framework boundary where the automatic behavior actually occurs.

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

Repeating manual ModelState checks while relying on [ApiController].
Treating automatic request validation as complete domain validation.
Relying on binding inference where the public source is ambiguous.
Changing the automatic error shape without testing existing clients.

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

Details

Every invalid operation is returned as the same generic 400 response.
The team cannot explain why an action breakpoint is never reached.
A controller accepts several body-bound parameters.
OpenAPI and actual validation responses disagree without contract tests.

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.

Why can an invalid request return before the action runs?
When would you use an explicit [FromBody] or [FromQuery]?
How would you customize automatic validation errors safely?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Problem Details vs Custom Error

Prerequisite

Review this first if the current drill feels shaky.

Binding vs Validation

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

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

Concept questionEasy~5 min

Interview question

What does `[ApiController]` change for an ASP.NET Core controller, especially around routing, binding, and validation errors?

ApiController conventions and automatic validation responses

Explains attribute routing, binding-source inference, automatic validation responses, and where explicit domain validation still belongs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Controller conventions, automatic HTTP 400 responses, `ModelState`, `ValidationProblemDetails`, binding-source inference, and domain validation boundaries.

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
[ApiController] removes repetitive controller plumbing, but only when its conventions and limits are understood. Automatic request validation is not the same as validating a business operation.
[ApiController] enables API-focused controller conventions. It requires attribute routing, infers common binding sources, and automatically returns a 400 response when binding or input validation leaves ModelState invalid. That removes routine ModelState checks, but it does not replace business rules such as ownership, stock availability, or valid state transitions.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I still use an explicit request DTO and binding attributes when the public source would be ambiguous. The automatic 400 normally uses ValidationProblemDetails, so I keep that shape aligned with the rest of the API's error contract. If I suppress the automatic response or customize it, the application owns equivalent behavior and tests.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
These conventions are part of the wire contract. Changing nullability, validation attributes, JSON settings, or parameter binding can reject a request before the action runs. I distinguish malformed input from business conflicts and authorization failures instead of returning 400 for everything. A small set of real HTTP contract tests proves the status and problem shape at the framework boundary where the automatic behavior actually occurs.

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

Repeating manual ModelState checks while relying on [ApiController].
Treating automatic request validation as complete domain validation.
Relying on binding inference where the public source is ambiguous.
Changing the automatic error shape without testing existing clients.

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

Details

Every invalid operation is returned as the same generic 400 response.
The team cannot explain why an action breakpoint is never reached.
A controller accepts several body-bound parameters.
OpenAPI and actual validation responses disagree without contract tests.

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.

Why can an invalid request return before the action runs?
When would you use an explicit [FromBody] or [FromQuery]?
How would you customize automatic validation errors safely?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Problem Details vs Custom Error

Prerequisite

Review this first if the current drill feels shaky.

Binding vs Validation

What does `[ApiController]` change for an ASP.NET Core controller, especially around routing, binding, and validation errors?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Prerequisite

What does `[ApiController]` change for an ASP.NET Core controller, especially around routing, binding, and validation errors?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Prerequisite