短.beコンテンツネゴシエーション (Content Negotiation) とは、HTTP 通信においてクライアント (ブラウザー) とサーバーが、リクエストされたリソースの最適な表現形式を交渉する仕組みです。同じ URL に対して、ユーザーの言語設定、デバイス、対応フォーマットに応じて異なるコンテンツを返すことができます。
コンテンツネゴシエーションは主に HTTP リクエストヘッダーを通じて行われます。Accept ヘッダー (対応するメディアタイプ: text/html、application/json など)、Accept-Language ヘッダー (希望する言語: ja、en-US など)、Accept-Encoding ヘッダー (対応する圧縮方式: gzip、br など) が代表的です。いずれのヘッダーも値に q を添えて優先度を示せます。Accept-Encoding: br, gzip;q=0.8 は br を第一希望とし、非対応なら gzip でよいという意味になります。サーバーがこれらのヘッダーを見て応答を変える場合は、判断に使ったヘッダー名を Vary で返す必要があります。Vary: Accept-Language を付け忘れると、キャッシュや CDN が最初に届いた言語の応答を後続の利用者にも配ってしまいます。
多言語サイトでのコンテンツネゴシエーションは、短縮 URL と密接に関わります。同じ短縮 URL をクリックしても、ユーザーのブラウザー言語設定に応じて日本語ページや英語ページにリダイレクトする実装が可能です。ただし、SEO の観点では、言語ごとに異なる URL を持ち、hreflang タグで関連付ける方が推奨されます。コンテンツネゴシエーションによる言語切り替えは、検索エンジンが各言語版を正しくインデックスできない場合があるためです。Google も、Cookie やブラウザー設定で表示を切り替えるのではなく言語版ごとに別の URL を用意する方法を案内しており、ある言語版から別の言語版へ自動的にリダイレクトすることは避けるよう求めています。自動リダイレクトは、利用者と検索エンジンの双方がすべての版に到達できなくなる原因になります。Google のクローラーはリクエストに Accept-Language を付けずに巡回するため、このヘッダーだけで表示を切り替えると既定の言語版しか読み取られません。IP アドレスから地域を推定して内容を変える方法も避けるよう案内されています。
API の設計でもコンテンツネゴシエーションは重要です。短縮 URL サービスの API が、Accept ヘッダーに応じて JSON または XML でレスポンスを返す実装は一般的です。同じリソースに対して複数の表現形式を用意しておくと、利用側は自分が扱える形式を選べます。ただし、どの表現を返すかを選ぶアルゴリズムは HTTP の仕様では定められておらず、サーバーの実装に委ねられています。要求された形式に対応できないときに 406 (Not Acceptable) を返すか、ヘッダーを無視して既定の形式を返すかも実装側の判断になります。
コンテンツネゴシエーションには、サーバー駆動型 (サーバーがリクエストヘッダーを見て判断) とエージェント駆動型 (サーバーが選択肢を提示し、クライアントが選択) の 2 種類があります。HTTP の仕様では前者を proactive negotiation、後者を reactive negotiation と呼びます。実際に使われるのは前者が中心ですが、ヘッダーからの推測が常にある程度は恣意的になるという弱点と引き換えです。後者が広まらなかったのは、選択肢を提示するページの形式が仕様で定められておらず選択を自動化できないことと、本来のリソースを取得するまでに往復が 1 回増えることが理由です。