Architecture scenarioMedium~7 minASP.NET Core Framework Essentials / 25 of 26

Interview question

What JSON serialization decisions in an ASP.NET Core API can become breaking contract changes, and how would you manage them?

JSON serialization as an ASP.NET Core API contract

Treats serializer naming, nulls, enums, converters, dates, references, and polymorphism as versioned client-facing behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

ASP.NET Core uses System.Text.Json by default for JSON APIs, and its options shape the public wire contract. Property naming, case matching, whether null or default values are omitted, enum representation, date and time formats, number handling, custom converters, and reference behavior can all change payloads without changing an endpoint route. I expose request and response DTOs designed for the contract instead of serializing EF entities or domain graphs directly. Global options remain consistent across endpoints, while an endpoint-specific exception is rare and documented. Before changing an option or converter, I compare representative old and new payloads and treat incompatible output or newly rejected input as an API change.

Full answer below

Practice focus

System.Text.Json, MVC and minimal API options, DTO contracts, naming, null handling, enums, dates, converters, reference cycles, polymorphism, and compatibility testing.

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 C# response type is not the wire contract by itself. Serializer settings and converters decide what clients actually send and receive, and small defaults can become durable dependencies.
ASP.NET Core uses System.Text.Json by default for JSON APIs, and its options shape the public wire contract. Property naming, case matching, whether null or default values are omitted, enum representation, date and time formats, number handling, custom converters, and reference behavior can all change payloads without changing an endpoint route. I expose request and response DTOs designed for the contract instead of serializing EF entities or domain graphs directly. Global options remain consistent across endpoints, while an endpoint-specific exception is rare and documented. Before changing an option or converter, I compare representative old and new payloads and treat incompatible output or newly rejected input as an API change.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Controller formatters are configured through MVC JSON options, while minimal APIs have their own HTTP JSON option surface, so a mixed application can drift if only one is configured. Returning a JsonResult with local options can also bypass the expected global behavior. I define intentional handling for enums and unknown values, UTC or offset-aware timestamps, required and optional members, dictionaries, and numeric precision. Reference-cycle suppression may hide data rather than fix a poor response shape, and unrestricted polymorphic deserialization creates both compatibility and security risk. OpenAPI examples and schemas help clients, but they need to match the actual serializer configuration and converters.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For evolution I favor additive DTO changes and explicit version boundaries over global serializer switches. A naming-policy change can rename every field; changing enums from numbers to strings can break strict clients; omitting nulls can change the difference between unknown, cleared, and absent; and a custom converter can make deserialization asymmetric with serialization. I keep golden payload or contract tests for important endpoints, including unknown fields, missing fields, invalid enum values, time zones, large numbers, and backward-compatible reads. I monitor deserialization failures without logging sensitive bodies. Source-generated serialization can improve startup, throughput, and trimming behavior, but its registered type metadata becomes another deployment contract that needs coverage. When clients span several versions, I first measure their real tolerance, publish the migration, and preserve the old shape long enough for controlled adoption rather than relying on permissive local JavaScript behavior.

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

Serializing persistence entities and navigation graphs directly.
Changing a global naming or enum policy as if it were internal refactoring.
Fixing reference cycles by silently dropping data from every response.
Configuring controller JSON options while assuming minimal APIs use the same options.

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

Details

The team cannot produce an exact example of the public JSON shape.
Serializer changes ship without old-client contract tests.
Custom converters accept ambiguous or unsafe polymorphic input.
Deserialization failures are debugged by logging complete request bodies.

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 changing enum serialization be breaking?
How can controller and minimal API JSON settings drift?
When would you use a custom converter?

Continue the section

Next in ASP.NET Core Framework Essentials: Response Already Started

Step 26 of 26

Response started and late exceptions in ASP.NET Core

Opening drill

Architecture scenarioMedium~7 minASP.NET Core Framework Essentials / 25 of 26

Interview question

What JSON serialization decisions in an ASP.NET Core API can become breaking contract changes, and how would you manage them?

JSON serialization as an ASP.NET Core API contract

Treats serializer naming, nulls, enums, converters, dates, references, and polymorphism as versioned client-facing behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

System.Text.Json, MVC and minimal API options, DTO contracts, naming, null handling, enums, dates, converters, reference cycles, polymorphism, and compatibility testing.

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 C# response type is not the wire contract by itself. Serializer settings and converters decide what clients actually send and receive, and small defaults can become durable dependencies.
ASP.NET Core uses System.Text.Json by default for JSON APIs, and its options shape the public wire contract. Property naming, case matching, whether null or default values are omitted, enum representation, date and time formats, number handling, custom converters, and reference behavior can all change payloads without changing an endpoint route. I expose request and response DTOs designed for the contract instead of serializing EF entities or domain graphs directly. Global options remain consistent across endpoints, while an endpoint-specific exception is rare and documented. Before changing an option or converter, I compare representative old and new payloads and treat incompatible output or newly rejected input as an API change.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Controller formatters are configured through MVC JSON options, while minimal APIs have their own HTTP JSON option surface, so a mixed application can drift if only one is configured. Returning a JsonResult with local options can also bypass the expected global behavior. I define intentional handling for enums and unknown values, UTC or offset-aware timestamps, required and optional members, dictionaries, and numeric precision. Reference-cycle suppression may hide data rather than fix a poor response shape, and unrestricted polymorphic deserialization creates both compatibility and security risk. OpenAPI examples and schemas help clients, but they need to match the actual serializer configuration and converters.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For evolution I favor additive DTO changes and explicit version boundaries over global serializer switches. A naming-policy change can rename every field; changing enums from numbers to strings can break strict clients; omitting nulls can change the difference between unknown, cleared, and absent; and a custom converter can make deserialization asymmetric with serialization. I keep golden payload or contract tests for important endpoints, including unknown fields, missing fields, invalid enum values, time zones, large numbers, and backward-compatible reads. I monitor deserialization failures without logging sensitive bodies. Source-generated serialization can improve startup, throughput, and trimming behavior, but its registered type metadata becomes another deployment contract that needs coverage. When clients span several versions, I first measure their real tolerance, publish the migration, and preserve the old shape long enough for controlled adoption rather than relying on permissive local JavaScript behavior.

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

Serializing persistence entities and navigation graphs directly.
Changing a global naming or enum policy as if it were internal refactoring.
Fixing reference cycles by silently dropping data from every response.
Configuring controller JSON options while assuming minimal APIs use the same options.

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

Details

The team cannot produce an exact example of the public JSON shape.
Serializer changes ship without old-client contract tests.
Custom converters accept ambiguous or unsafe polymorphic input.
Deserialization failures are debugged by logging complete request bodies.

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 changing enum serialization be breaking?
How can controller and minimal API JSON settings drift?
When would you use a custom converter?

Continue the section

Next in ASP.NET Core Framework Essentials: Response Already Started

Step 26 of 26

Response started and late exceptions in ASP.NET Core

What JSON serialization decisions in an ASP.NET Core API can become breaking contract changes, and how would you manage them?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What JSON serialization decisions in an ASP.NET Core API can become breaking contract changes, and how would you manage them?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section