Concept questionMedium~7 min

Interview question

What is the difference between Content-Type and Accept, and how should an API handle content negotiation?

Content-Type, Accept, and HTTP content negotiation

Distinguishes request and response media types and designs predictable negotiation, rejection, documentation, and caching behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Content-Type describes the representation being sent in the current message, such as an application/json request body. Accept tells the server which response media types the client can handle. If the request media type is unsupported, the API can return 415. If it cannot produce an acceptable response representation, it can return 406 when strict negotiation is enabled. I keep the normal contract simple, usually JSON, and document the supported request and response types.

Full answer below

Practice focus

Media types, Content-Type, Accept, 415, 406, charset, vendor media types, ASP.NET Core formatters, OpenAPI, and Vary.

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
Media types tell both sides how to interpret representation bytes. Treating every body as implicit JSON works until a client sends or requests something the endpoint does not actually support.
Content-Type describes the representation being sent in the current message, such as an application/json request body. Accept tells the server which response media types the client can handle. If the request media type is unsupported, the API can return 415. If it cannot produce an acceptable response representation, it can return 406 when strict negotiation is enabled. I keep the normal contract simple, usually JSON, and document the supported request and response types.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
In ASP.NET Core, input and output formatters plus endpoint metadata participate in this behavior. I do not advertise XML, CSV, or a vendor media type unless the implementation and tests actually support it. Content-Type parameters such as charset are part of the media type handling, and uploads may use multipart content rather than JSON. If the response can vary by Accept, caches need the correct Vary behavior so one negotiated representation is not served to a client that requested another.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat negotiation as a versioned contract surface. A vendor media type can carry version information, but URL or header versioning may be clearer for the clients and tooling involved. I define a deterministic default when Accept is broad, reject unsupported formats honestly, and make OpenAPI describe the same media types the runtime accepts and produces. Quality values in Accept can express client preference, but the server still chooses only among representations it supports and should resolve ties predictably. Compression is content coding, not media-type negotiation, so Accept-Encoding and Content-Encoding are handled separately. Production telemetry records unsupported media types and negotiation failures without logging sensitive bodies.

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

Using Accept to describe the request body.
Silently parsing an unsupported Content-Type as JSON.
Advertising response formats that are not exercised by contract tests.
Forgetting cache variation when responses differ by Accept.

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

Details

The API guesses the payload format from body content.
OpenAPI and runtime media types disagree.
A cache can mix JSON, XML, or versioned representations.
Clients receive a fallback format they explicitly cannot process.

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.

When would 415 and 406 be returned?
How is Accept-Encoding different from Accept?
What would make a vendor media type worthwhile?

Continue practice

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

1 linked

Go deeper

Practice the next layer of the same subject.

OpenAPI Contract

Opening drill

Concept questionMedium~7 min

Interview question

What is the difference between Content-Type and Accept, and how should an API handle content negotiation?

Content-Type, Accept, and HTTP content negotiation

Distinguishes request and response media types and designs predictable negotiation, rejection, documentation, and caching behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Media types, Content-Type, Accept, 415, 406, charset, vendor media types, ASP.NET Core formatters, OpenAPI, and Vary.

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
Media types tell both sides how to interpret representation bytes. Treating every body as implicit JSON works until a client sends or requests something the endpoint does not actually support.
Content-Type describes the representation being sent in the current message, such as an application/json request body. Accept tells the server which response media types the client can handle. If the request media type is unsupported, the API can return 415. If it cannot produce an acceptable response representation, it can return 406 when strict negotiation is enabled. I keep the normal contract simple, usually JSON, and document the supported request and response types.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
In ASP.NET Core, input and output formatters plus endpoint metadata participate in this behavior. I do not advertise XML, CSV, or a vendor media type unless the implementation and tests actually support it. Content-Type parameters such as charset are part of the media type handling, and uploads may use multipart content rather than JSON. If the response can vary by Accept, caches need the correct Vary behavior so one negotiated representation is not served to a client that requested another.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat negotiation as a versioned contract surface. A vendor media type can carry version information, but URL or header versioning may be clearer for the clients and tooling involved. I define a deterministic default when Accept is broad, reject unsupported formats honestly, and make OpenAPI describe the same media types the runtime accepts and produces. Quality values in Accept can express client preference, but the server still chooses only among representations it supports and should resolve ties predictably. Compression is content coding, not media-type negotiation, so Accept-Encoding and Content-Encoding are handled separately. Production telemetry records unsupported media types and negotiation failures without logging sensitive bodies.

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

Using Accept to describe the request body.
Silently parsing an unsupported Content-Type as JSON.
Advertising response formats that are not exercised by contract tests.
Forgetting cache variation when responses differ by Accept.

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

Details

The API guesses the payload format from body content.
OpenAPI and runtime media types disagree.
A cache can mix JSON, XML, or versioned representations.
Clients receive a fallback format they explicitly cannot process.

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.

When would 415 and 406 be returned?
How is Accept-Encoding different from Accept?
What would make a vendor media type worthwhile?

Continue practice

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

1 linked

Go deeper

Practice the next layer of the same subject.

OpenAPI Contract

What is the difference between Content-Type and Accept, and how should an API handle content negotiation?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

What is the difference between Content-Type and Accept, and how should an API handle content negotiation?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper