Content Negotiation
Content negotiation is how HTTP picks one version of a resource from the client's preferences and the server's available formats.
Another example
A report API sends `application/json` or `text/csv` based on `Accept`. It returns 406 if neither works and adds `Vary: Accept`. This stops a cache from sending CSV to a JSON client. Language is chosen separately, and every reply has a clear `Content-Type`.
Main parts
- 01Client preferences
- 02Available representations
- 03Selected response and Vary
Use it when
Use standard request headers when one resource truly has different media, language, encoding, or preference versions.
Do not use it when
Do not make versions that caches cannot tell apart. Do not quietly ignore a required media type that the server does not support.
Name used in code
Accept / Accept-Language / Accept-Encoding + Content-Type / Content-Language + Vary Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Content Negotiation for this system while keeping data correct, secure, and easy to operate. User context: A report API sends `application/json` or `text/csv` based on `Accept`. It returns 406 if neither works and adds `Vary: Accept`. This stops a cache from sending CSV to a JSON client. Language is chosen separately, and every reply has a clear `Content-Type`. Technical concept or control: Content Negotiation. Why it fits: Use standard request headers when one resource truly has different media, language, encoding, or preference versions. Do not use it when: Do not make versions that caches cannot tell apart. Do not quietly ignore a required media type that the server does not support. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Content Negotiation. Definition: Content negotiation is how HTTP picks one version of a resource from the client's preferences and the server's available formats. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.