Concept questionEasy~6 minASP.NET Core Framework / 23 of 26

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 web-API conventions for a controller or assembly. It requires attribute routing, infers common binding sources for action parameters, and returns an automatic HTTP 400 response when model binding or validation leaves ModelState invalid. The default validation response uses ValidationProblemDetails, so an action usually does not need an if (!ModelState.IsValid) block. These behaviors cover whether the incoming request can be bound to the declared shape and satisfies configured input rules. They do not decide business outcomes such as whether an email is already registered, an order can still be cancelled, or the caller owns a resource; those checks remain explicit application behavior with appropriate status codes.

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 web-API conventions for a controller or assembly. It requires attribute routing, infers common binding sources for action parameters, and returns an automatic HTTP 400 response when model binding or validation leaves ModelState invalid. The default validation response uses ValidationProblemDetails, so an action usually does not need an if (!ModelState.IsValid) block. These behaviors cover whether the incoming request can be bound to the declared shape and satisfies configured input rules. They do not decide business outcomes such as whether an email is already registered, an order can still be cancelled, or the caller owns a resource; those checks remain explicit application behavior with appropriate status codes.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Binding inference can treat complex types as body input, route-name matches as route values, and registered service types as services, but I use explicit attributes when the public contract would otherwise be ambiguous. Only one request body can be consumed by the normal body formatter, so I define one request DTO rather than several body parameters. I keep the automatic 400 shape consistent with the API's broader Problem Details contract and customize InvalidModelStateResponseFactory only when clients need stable extensions such as application error codes or trace identifiers. If automatic behavior is suppressed, the application owns the equivalent validation path and must test it.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat these conventions as part of the externally observable API. Changing nullable annotations, validation attributes, JSON options, parameter types, or binding attributes can turn a formerly accepted request into an automatic 400 before the action executes. That means logs placed only inside the action miss the failure, and filters or metrics need to observe the framework boundary deliberately. I distinguish malformed input, syntactically valid but rule-breaking input, current-state conflicts, authorization failures, and unexpected exceptions instead of mapping every rejection to 400. Contract tests send real HTTP requests through the pipeline and assert status, content type, problem type or code, field paths, and safe details. OpenAPI should describe the same required fields and responses, but runtime tests remain the proof because conventions, custom filters, and serializer settings can drift from generated documentation.

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 the section

Next in ASP.NET Core Framework: Kestrel & Reverse Proxy

Step 24 of 26

Kestrel and reverse proxy responsibilities in ASP.NET Core

Opening drill

Concept questionEasy~6 minASP.NET Core Framework / 23 of 26

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 web-API conventions for a controller or assembly. It requires attribute routing, infers common binding sources for action parameters, and returns an automatic HTTP 400 response when model binding or validation leaves ModelState invalid. The default validation response uses ValidationProblemDetails, so an action usually does not need an if (!ModelState.IsValid) block. These behaviors cover whether the incoming request can be bound to the declared shape and satisfies configured input rules. They do not decide business outcomes such as whether an email is already registered, an order can still be cancelled, or the caller owns a resource; those checks remain explicit application behavior with appropriate status codes.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Binding inference can treat complex types as body input, route-name matches as route values, and registered service types as services, but I use explicit attributes when the public contract would otherwise be ambiguous. Only one request body can be consumed by the normal body formatter, so I define one request DTO rather than several body parameters. I keep the automatic 400 shape consistent with the API's broader Problem Details contract and customize InvalidModelStateResponseFactory only when clients need stable extensions such as application error codes or trace identifiers. If automatic behavior is suppressed, the application owns the equivalent validation path and must test it.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat these conventions as part of the externally observable API. Changing nullable annotations, validation attributes, JSON options, parameter types, or binding attributes can turn a formerly accepted request into an automatic 400 before the action executes. That means logs placed only inside the action miss the failure, and filters or metrics need to observe the framework boundary deliberately. I distinguish malformed input, syntactically valid but rule-breaking input, current-state conflicts, authorization failures, and unexpected exceptions instead of mapping every rejection to 400. Contract tests send real HTTP requests through the pipeline and assert status, content type, problem type or code, field paths, and safe details. OpenAPI should describe the same required fields and responses, but runtime tests remain the proof because conventions, custom filters, and serializer settings can drift from generated documentation.

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 the section

Next in ASP.NET Core Framework: Kestrel & Reverse Proxy

Step 24 of 26

Kestrel and reverse proxy responsibilities in ASP.NET Core

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 the section

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 the section