メインコンテンツまでスキップ

1. Introduction (はじめに)

条件付きリクエストは, ターゲットリソースにメソッドセマンティクスを適用する前にテストする前提条件を示す1つ以上のヘッダーフィールドを含む HTTP リクエスト [RFC7231] です。この文書は, [RFC7230] で定義されているアーキテクチャ, 構文表記, および適合性基準の観点から HTTP/1.1 条件付きリクエストメカニズムを定義します。

条件付き GET リクエストは, HTTP キャッシュ更新のための最も効率的なメカニズムです [RFC7234]。条件付きリクエストは, PUT や DELETE などの状態変更メソッドにも適用でき, "失われた更新" 問題を防ぎます: あるクライアントが並行して動作している別のクライアントの作業を誤って上書きすることを防ぎます。

条件付きリクエストの前提条件は, ターゲットリソースの全体的な状態 (現在の値セット) または以前に取得した表現で観察された状態 (そのセット内の1つの値) に基づいています。リソースには複数の現在の表現があり, それぞれに独自の観察可能な状態があります。条件付きリクエストメカニズムは, サーバーが条件を利用する意図がある場合, リクエストから "選択された表現" (selected representation) ([RFC7231] のセクション 3 参照) へのマッピングが時間の経過とともに一貫していることを前提としています。いずれにしても, マッピングが一貫しておらず, サーバーが適切な表現を選択できない場合でも, 前提条件が false と評価されたときに害は生じません。

この仕様で定義された条件付きリクエストの前提条件 (セクション 3) は, 受信者に適用可能な場合 (セクション 5) に優先順位 (セクション 6) に従って評価されます。

1.1. Conformance and Error Handling (適合性とエラー処理)​

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は, [RFC2119] に記載されているように解釈されるものとします。

  • MUST / REQUIRED / SHALL: しなければならない
  • MUST NOT / SHALL NOT: してはならない
  • SHOULD / RECOMMENDED: すべきである
  • SHOULD NOT / NOT RECOMMENDED: すべきではない
  • MAY / OPTIONAL: してもよい

エラー処理に関する適合性基準と考慮事項は, [RFC7230] のセクション 2.5 で定義されています。

1.2. Syntax Notation (構文表記)​

この仕様は, [RFC5234] の拡張バッカス・ナウア記法 (Augmented Backus-Naur Form, ABNF) 表記法を使用し, [RFC7230] のセクション 7 で定義されたリスト拡張を使用します。これにより, '#' 演算子を使用してコンマ区切りリストをコンパクトに定義できます ('*' 演算子が繰り返しを示すのと同様)。付録 B は他の文書からインポートされたルールを説明しています。付録 C は, すべてのリスト演算子が標準 ABNF 表記法に展開された収集された文法を示しています。

に最終更新