miji.beContent negotiation is the HTTP mechanism by which a client (browser) and server agree on the best representation of a requested resource. The same URL can return different content depending on the user's language preference, device capabilities, or supported formats.
Negotiation happens primarily through HTTP request headers. The Accept header specifies supported media types (text/html, application/json, etc.), Accept-Language specifies preferred languages (ja, en-US, etc.), and Accept-Encoding specifies supported compression methods (gzip, br, etc.). Any of these headers can carry q values to express preference: Accept-Encoding: br, gzip;q=0.8 asks for br first and accepts gzip otherwise. Whenever a server varies its response based on such headers, it has to name them in a Vary header. Omitting Vary: Accept-Language lets a cache or CDN serve the first language it received to everyone who follows.
Content negotiation intersects with shortened URLs in multilingual sites. A single short link can redirect to a Japanese or English page based on the browser's language setting. However, from an SEO standpoint, having distinct URLs per language with hreflang tags is preferred, because content negotiation can prevent search engines from correctly indexing each language version. Google likewise recommends a separate URL for each language version instead of switching on cookies or browser settings, and asks site owners to avoid redirecting visitors automatically from one language version to another, since such redirects can stop both people and search engines from reaching every version. Google's crawler also issues requests without an Accept-Language header, so a site that switches on that header alone exposes only its default language to crawling. Adapting content from IP-based location is discouraged for the same reason.
In API design, content negotiation is equally important. A URL shortening API that returns JSON or XML depending on the Accept header is a common pattern. Offering several representations of the same resource lets each client pick a format it can handle. The algorithm that chooses among them is not defined by HTTP, though; it is left to the server implementation. Whether an unsupported request yields 406 (Not Acceptable) or simply the default representation is an implementation decision as well.
Two types of content negotiation exist: server-driven (the server inspects request headers and decides) and agent-driven (the server presents options and the client chooses). HTTP calls the first proactive negotiation and the second reactive negotiation. Server-driven negotiation dominates in practice, but its trade-off is that a decision inferred from headers is always somewhat arbitrary. Agent-driven negotiation never caught on because the format of the page listing the options is not specified, which prevents the choice from being automated, and because it costs one extra round trip before the real resource arrives.