3.1. Generic Semantics (汎用セマンティクス)

3.1. Generic Semantics (汎用セマンティクス)

HTTP の価値の多くはその汎用セマンティクスにあります。つまり, HTTP によって定義されたプロトコル要素は潜在的にすべてのリソースに適用可能であり, 特定のコンテキストに固有ではありません。アプリケーション固有のセマンティクスは, ステータスコードやメソッドではなく, メッセージコンテンツとヘッダーフィールドで表現するのが最適です (ただし, ステータスコードとメソッドはアプリケーション状態に関連する汎用セマンティクスを持っています)。

汎用セマンティクスとアプリケーション固有のセマンティクスのこの分離により, HTTP メッセージを共通のソフトウェア (例: HTTP サーバー, 中間者, クライアント実装, キャッシュ) で処理できます。これらの実装は使用中のアプリケーションを理解する必要がありません。また, 特定のアプリケーションの専門知識を必要とせずに, HTTP セマンティクスの知識を活用できます。

したがって, HTTP を使用するアプリケーションは, メソッド, ステータスコード, 既存のヘッダーフィールドなどの汎用プロトコル要素のセマンティクスを再定義, 洗練, またはオーバーレイしてはなりません (MUST NOT)。代わりに, アプリケーション固有のプロトコル要素, つまり HTTP リソースに仕様を集中させるべきです。

詳細については [BCP190] を参照してください。

仕様を書くとき, HTTP の実装, サポート, および使用方法を正確に指定したくなることがよくあります。しかし, これは HTTP の動作の意図しないプロファイルにつながりやすくなります。たとえば, 次のような言語を持つ仕様を見ることは一般的です:

POST リクエストは 201 Created レスポンスを生成しなければなりません (MUST)。

これはクライアントに, レスポンスが常に 201 Created であるという期待を形成しますが, 実際にはそのレスポンスはまったく確実ではありません。サーバーが新しいリソースが作成されたと判断した場合にのみ期待されますが, さまざまな理由 (セキュリティポリシーなど) により, サーバーが新しいリソースを作成したり, リソースが作成されたことを確認したりすることが妨げられる可能性があります。

より適切な言語は次のようになります:

成功した POST リクエストは, リソースが作成されたときに 201 Created レスポンスを生成すべきです (SHOULD)。

仕様は, プロトコル要素の特定のインスタンスを使用して, アプリケーション固有のセマンティクスを示すことができます。ある意味で, これは汎用セマンティクスがアプリケーション用に専門化される方法です。たとえば, アプリケーションは特定の Content-Type を持つ POST リクエストが "囲まれた表現で新しいリソースを作成する" ことを意味すると定義する場合があります。セマンティクスはアプリケーション固有であるため, アプリケーションの仕様で定義する必要があります。

アプリケーション定義のヘッダーフィールドの詳細については, セクション 4.7 を参照してください。