A URIを特定することを意図しているリソースを。
リソースとは、取得される実際のものを指します。ウェブサイトでは、通常はページです。REST APIでは、通常、エンティティ、人物、プロフィール、ウィジェット、写真などです。
HTTPヘッダーはサーバーにクライアントについての情報を伝えます -それらはリソース自体については何も記述しておらず、そのリソースを見つけるためのヘルプも提供していません。
例えば：
Accept-Encoding クライアントが特定のコンテンツを変換または解凍する方法を知っていることをサーバーに伝えます。Accept-Language クライアントが特定のロケールにあることをサーバーに通知し、そのロケールのコンテンツを優先します。Authorization 保護されたリソースへのアクセスが許可されているとクライアントが考えていることをサーバーに通知します。
これらの要求ヘッダーの大部分に共通するテーマは、サーバーがそれらを尊重する義務がないことです。Accept-Encodingのは、gzip応答が圧縮されることを保証するものではありません。の一部Accept-Languageはur-PK、ウルドゥー語を特にサポートしていない限り、米国のサイトにアクセスしても無視される可能性があります。また、サーバーは、Authorizationヘッダーが正しいかどうかを確認し、表示が適切でない場合は401または403を返す権利を留保します。
これらのヘッダーはいずれも、サーバーが応答として提供するリソースについての実質的な変更を意図したものではありません。Acceptヘッダは、違いはありません。クライアントが指定application/xmlし、サーバーがのみをサポートするapplication/json場合、サーバーはXMLではなくJSONを送り返します。さらに重要なことは、Acceptヘッダーで複数のタイプを指定できることです。その場合、サーバーは自由に（またはそれらのいずれも）返すことができます。ご想像のとおり、これはユーザーにとって未定義の動作に簡単につながる可能性がありますが、当面は無視してください。
ハイパーリンクの目的は、特定のタイプのリソースであるページにリンクすることです。あるいは、リソースがページ以外の何か（おそらく画像やデータセット）であっても、リソースに単純にリンクするというより緩い定義で正当化される場合があります。ただし、これが明らかに意図していないことは、リソースの特定の表現へのリンクです。これは、クライアントとサーバーがネゴシエートし、サーバーが最終的に決定するためのものです。
Accept-Languageハイパーリンクでヘッダーを制御できるようにすることが問題になる理由の明白な例です。考えてみれば、あまり意味がありません。各ユーザーは自分の言語設定を制御します。オペレーティングシステムやブラウザで設定されています。どのページにアクセスしているかに関係なく、ブラウザーは常に同じ Accept-Languageヘッダーを送信する必要があります。サーバーがその言語をサポートしている場合、すばらしいです。そうでない場合は、最も近いと思われる言語で応答します。
ハイパーリンクによってこれが変更される可能性がある場合、ブラウザーとオペレーティングシステムがその言語をサポートするように構成されていない場合でも、着信リンクによってサイトの中国語バージョンに強制的に移動できます。それは意味がありません。サイトが英語をサポートし、ブラウザが英語の場合、ハイパーリンクの内容に関係なく、英語で応答するはずです。
同様に、ブラウザーがXMLを構造化データとして表示する方法を知っていて、XSLを探して見栄えをよくすることができるが、JSONをどうするかわからない場合は、プレーンテキストとしてダンプしてから、リンクを介したJSONコンテンツ（そのようなことが可能である場合）は、積極的にユーザーに敵対的な行動です。「Xを表示する方法は知っているが、Yは知らないので、ブラウザは常にXを提供してくれればいいのに」と言うべきです。
ブラウザーのユーザーがこの決定をオーバーライドできるようにするのが論理的であると考える理由が理解できます。しかし、問題の真実は、あなたがレポートのダウンロードのようないくつかの小さなエッジケースを考えているということです。99％の確率で、この選択が存在する場合、ユーザーは資格を持たないか、それを行うための十分な情報を持っていません。
少し言い方を変えると、両親や祖父母がファイルをダウンロードしようとしていて、text / csvまたはtext / plainを選択するように求められているところを想像してみてください。彼らは違いを知っている可能性がありますか？私はあなたのことを知りませんが、バナー広告とエラーメッセージの違いを見つけることさえできないことがよくあります。そのため、彼らがこの選択をインテリジェントに行うことはできません。一方、「Excelワークブック」または「テキストのみ」をダウンロードするための個別のリンクが与えられている場合、希望がかすかに見える可能性があります。これらは、同じリソースの異なる表現ではなく、実際には個別のリソースです。 URIはそれを反映する必要があります。
ユーザーは、これらの2つが実際には同じリソースであり、表現が異なることを理解することはできません。そして、今日のWebの動作に関するすべてを変更することなく、そのハイパーリンクで何が行われるかについては何も推測できません。クリックするか、右クリックして[名前を付けて保存]を選択するか、コピーしてアドレスバーに貼り付けるか、ダウンロードマネージャーを使用しているか、IE6を使用しているか、または独自のブラウザを備えたブランド外のタブレットまたはモバイルデバイスを使用している可能性があります...これらの多くの場合、宣言したハイパーリンクの一部が失われるため、必要なコンテンツを取得できません。 content-type、またはブラウザはそれをサポートしません。
HTML仕様は、ハイパーリンクのコンテンツタイプ属性をサポートするように40年前に設計されたのでしょうか。たぶん、最初のいくつかの段落で説明したように、特に帯域幅とサーバーリソースが不足していて、同じレポートを複数の形式（または率直に言うと、すべてのレポートをダウンロードする）正直に言って誰にも起こりませんでした。しかし、確かに今日の世界では、そのようなものを仕様に追加するのはおかしいでしょう。それは完全に下位互換性を壊し、すべての既存のブラウザで恐ろしい「未定義の動作」を引き起こします。