Learn the vocabulary of a server choosing a response format based on what a client actually requests.
0 / 5 completed
1 / 5
At standup, a dev mentions a client sending an Accept header listing the response formats it can handle, and the server choosing which representation, like JSON or XML, to actually return based on that header. What is this mechanism called?
Content negotiation has the client send an Accept header listing the response formats it can handle, ranked by preference, and the server chooses which representation, such as JSON or XML, to actually return based on that header, letting the same underlying resource be served in whichever format a given client actually wants. A CORS preflight is an unrelated browser mechanism concerned with cross-origin permission, not response format selection. This negotiation is what lets a single API endpoint serve multiple client types without needing a separate URL for every possible representation.
2 / 5
During a design review, the team has the server also inspect an Accept-Language header, returning localized error messages in the language the client actually requested when more than one translation is available. Which capability does this extend content negotiation to cover?
This extends content negotiation to cover negotiating the response's language, not just its data format, based on what the client's Accept-Language header indicates it can understand, letting the same endpoint return a French error message to one client and an English one to another without needing separate localized endpoints. Content negotiation isn't limited to just data format; it's a general mechanism for choosing among any available representations, whether that variation is in format, language, compression, or something else. This language-aware extension is a natural, common use of the same negotiation mechanism already used for choosing between JSON and XML.
3 / 5
In a code review, a dev notices an endpoint always returns JSON regardless of what a client's Accept header actually requests, even when a client explicitly asks only for XML and can't parse JSON at all. What does this represent?
This is a content negotiation failure, since properly implemented negotiation is supposed to honor the client's stated preference in the Accept header, and ignoring it entirely to always return JSON means a client that genuinely can't parse JSON, and only requested XML, receives a response it has no way to actually use. A CSRF token is an unrelated defense against forged requests, not related to response format selection. This is exactly the kind of gap that breaks any client relying on real content negotiation rather than just happening to accept whatever format the server always sends.
4 / 5
An incident report shows a legacy integration partner's system broke completely after an API update, because the partner's client explicitly requested XML through its Accept header, but the updated endpoint had started ignoring that header and always returning JSON regardless of what was requested. What practice would prevent this?
Properly implementing content negotiation so the server actually inspects and honors the client's Accept header ensures a client explicitly requesting XML continues receiving XML, which is exactly what would have kept the legacy partner's integration working through this update. Continuing to always return JSON regardless of the requested format is precisely what broke that partner's system in this incident. This honoring-the-Accept-header behavior is the whole point of content negotiation, and skipping it defeats the mechanism's purpose even if the endpoint's URL still technically supports multiple formats in name.
5 / 5
During a PR review, a teammate asks why the team supports true content negotiation via the Accept header instead of just requiring every client to append a fixed format suffix to the URL, like requesting /users.json versus /users.xml explicitly. What is the reasoning?
A fixed URL suffix convention works, but it requires every client to already know and hardcode the exact suffix the API expects, and it multiplies the number of distinct URLs the API surface has to document and support. Accept-header-based negotiation instead lets a single, clean URL serve whichever format a given client already declares it can handle, without needing a separate URL per format. The tradeoff is that Accept-header negotiation requires the server to actually implement the negotiation logic correctly, including sensible fallback behavior when a client's preferred format isn't available, which is a bit more implementation effort than simply routing based on a URL suffix.