日本語翻訳:

まとめ

HTTP QUERY メソッドは、読み取り専用の GET リクエストと動作指向の POST リクエストの間の空白を埋め、複雑なデータを取得するための標準化された安全で冪等的な手段を提供します。反復実行時に予測不可能な副作用をもたらす可能性のある POST と異なり、QUERY は状態変化を保証するため、意図しないデータ変更を引き起こすリスクなしに複雑な検索に適しています。重要なのは、QUERY がクエリ入力を URI ではなくリクエスト本체에格納することで、既定の方法と同様に安全なリダイレクト処理を可能にすることです。プロトコルの整合性を確保するためには、サーバーは Content-Type ヘッダーを厳密に検証し、"Accept-Query" ヘッダーを通じてサポートの有無を信号化しなければなりません。QUERY はセキュリティプロトコルにおいてデフォルトでは自動的に安全とはみなされないため、クロスオリジンのリクエストを送信する前に、ブラウザは必須の CORS「プレフライト」チェックを実行する必要があります。リクエスト内容とメタデータを組み込んだ独自のキャッシュ戦略により、QUERY は開発者に効率的でステートレスなデータ取得ワークフローの実装を可能にし、既存の HTTP 動詞（POST や SEARCH など）に複雑なクエリを強制的に適用する際にしばしば生じる曖昧さを排除します。

HTTP プロトコル新規メソッド「QUERY」の仕様書：日本語訳と整理

HTTP プロトコルの新規メソッドとして QUERY を定義する仕様の日本語訳です。技術的な正確さを保ちつつ、要点を整理しました。

要約

本仕様では、HTTP メソッドとして QUERY メソッド が正式に定義されます。

** QUERY リクエストの特徴**
- 対象リソースに対して包摂されたコンテンツを含み、安全かつ冪等（idempotent）な処理を要求します。
- ```
POST
```
  リクエストと類似していますが、部分的な状態変化を意識せず設計されています。
- 接続失敗時など、自動的に繰り返し実行したり再起動したりすることが可能です。

本書のステータスと著作権

ステータス
- インターネット標準トラッカー（Internet Standards Track）文書です。
- IETF コミュニティの合意に基づき、IESG により出版が承認されました。
- 詳細情報：RFC 7841 第 2 節。
- 最新版およびフィードバック URL: https://www.rfc-editor.org/info/rfc10008
著作権表示
- (c) 2026 IETF Trust および文書著者。
- 発行時の BCP 78 および IETF Trust の法的規定に従います。
- コードコンポーネントは、保証なしの改訂 BSD ライセンス（Revised BSD License）下で提供されます。

1. はじめに

目的
- ターゲットリソースに対して表現（representation）を包摂し、安全かつ冪等なリクエストを作成する手段を提供します。
- ```
GET
```
  ではデータ量が多すぎて URI に符号化できない場合の解決策です。
- 一般的なクエリパターンにおいて、入力データをリクエストコンテンツとして渡す必要があります。
QUERY メソッドのメリット
- ```
POST
```
  の不透明性（安全・冪等性が不明確）を解消します。
- 明示的に安全かつ冪等であるため、キャッシュ機能や自動再試行の実装が可能になります。
- サーバーはクエリ自体または結果に対して URI を割り当てられる方法を記述し、将来的に
```
GET
```
  リクエストで使用するために予約する余地を残します。

用語と表記の慣習

用語
- ```
[HTTP]
```
  第 3 節で定義された用語を使用します。
- 「URI クエリパラメータ」：URI のクエリ成分にあるパラメータ（[HTTP] 4.2.2）。
- 「クエリコンテンツ」：
```
QUERY
```
  リクエストのリクエストコンテンツ（[HTTP] 6.4）。
表記の慣習
- ```
MUST
```
  ,
```
SHOULD
```
  ,
```
MAY
```
  など、BCP 14 [RFC2119][RFC8174] に従い、大文字で現れた場合のみ厳密に解釈されます。

2. QUERY メソッドの仕様

基本動作
- サーバーサイドでのクエリを開始するために使用されます。
- ```
GET
```
  と異なり、ターゲット URI ではなく対象リソース内でクエリ操作を実行するように要求します。
- リクエストコンテンツとメディアタイプがクエリを定義します。
応答コード
- 2xx（成功）：正常に受信・理解・承認されたことを示します。
  - ```
  200 OK
```
  ：クエリが正常に処理され、結果が含まれています。
- Content-Type リクエストヘッダーが存在しない場合または不一致の場合は、必ずリクエストを失敗させます（
```
MUST
```
  ）。
同等のリソース（Equivalent Resource）
- ```
QUERY
```
  リクエストに対する
```
GET
```
  リクエストと同等の表現を持ちます。
- サーバーはこのリソースに URI を割り当てることができます（必須ではありませんが推奨）。
- URI が割り当てられると、
```
GET
```
  メソッドで結果を参照できるようになります。
応答ヘッダーフィールド
- Content-Location：操作結果に対応するリソースの識別子を返します（一時的な可能性があります）。
- Location：同等のリソースの URI を返し、以降の
```
GET
```
  で同じクエリを再実行できるようにします。
  - 失敗した場合はオリジナルのターゲットとコンテンツを使って再試行可能です。
再指向（Redirection）
- サーバーはユーザーエージェントを別の URI に再指向できます。
- 301/308：恒久的な移動（新しい URI に対して
```
QUERY
```
  を推奨）。
- 302/307：一時的な移動。
- 303 (See Other)：元のクエリは通常の取得リクエスト（
```
GET
```
  ）で達成可能であることを示します。
条件付きリクエストとキャッシング
- 条件付き
```
QUERY
```
  は、選択された表現に対する
```
GET
```
  リクエストと同じ挙動をします。
- キャッシング対応：応答はキャッシュ可能です。
  - キャッシュキーにはリクエストコンテンツおよび関連メタデータを必ず含める必要があります（
```
MUST
```
    ）。
- レンジリクエスト：語義は
```
GET
```
  と同じですが、バイトレンジのみのクエリは QUERY 結果にはあまり価値がないため推奨されません。

3. Accept-Query ヘッダーフィールド

機能
- リソースが
```
QUERY
```
  メソッドをサポートし、使用可能なクエリフォーマットのメディアタイプを特定するために使用されます。
- メディアレンジのリスト（例：
```
application/x-www-form-urlencoded, application/json
```
  ）を含みます。
扱い方
- パラメータ付きの場合は「トークン型」または「ストリング型」で表されます（语义的に無意味）。
- 厳密なトークンのみのメディアタイプに一致せず、ワイルドカードは
```
*/*
```
  や
```
xxxx/*
```
  のみ使用可能です。
注意点
- 同じパスのすべての URI に適用されます（クエリ成分は無視）。
- 他のフィールドとは異なり、[STRUCTURED-FIELDS] 第 4 節に従った構造として処理される必要があります（
```
MUST
```
  ）。

4. セキュリティの考慮事項

ログ記録の影響
- ```
QUERY
```
  は URI に渡す代替手段となり得ます。
- 機密情報を含む場合、URI ログ記録のリスクは
```
GET
```
  と同様または更高い可能性があります。
- サーバーが一時的なリソースを作成する場合、URI は機密部分を含まないように選択すべきです（
```
SHOULD
```
  ）。
キャッシュと CORS
- キャッシュがコンテンツを誤って正常化し、偽陽性を生じさせるリスクがあります。
- 既存の CORS 実装ユーザーエージェントからの
```
QUERY
```
  リクエストは、「preflight」リクエストが必要（CORS-safelisted メソッドに含まれていないため）。

6. 参考文献

規範的参考文献 (Normative)

```
[HTTP]
```
RFC 9110: HTTP Semantics
```
[HTTP-CACHING]
```
RFC 9111: HTTP Caching
```
[RFC2119]
```
BCP 14: Key words for use in RFCs
```
[RFC8174]
```
BCP 14: Ambiguity of Uppercase vs Lowercase
```
[STRUCTURED-FIELDS]
```
RFC 9651: Structured Field Values for HTTP
```
[URI]
```
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax

情報的参考文献 (Informative)

```
[FETCH]
```
WHATWG Living Standard: FETCH
```
[RFC3253]
```
WebDAV Versioning Extensions
```
[RFC4918]
```
HTTP Extensions for WebDAV
```
[RFC5323]
```
WebDAV SEARCH
```
[RFC6838]
```
Media Type Specifications
```
[RFC8259]
```
The JavaScript Object Notation (JSON) Data Interchange Format
```
[RFC9535]
```
JSONPath: Query Expressions for JSON
```
[URL]
```
WHATWG Living Standard: URL
```
[XSLT]
```
W3C Recommendation: XSL Transformations (XSLT) Version 3.0

付録 A. 例

多くの例で使用されるメディアタイプは

application/x-www-form-urlencoded

です。簡略化のため Content-Length フィールドは省略されています。

A.1. シンプルなクエリ

直接応答を返すシンプルなクエリの例です。

A.2. QUERY サポートの発見

OPTIONS

メソッド（

Allow

ヘッダー）を使用して、リソースが

QUERY

をサポートしているか確認できます。

A.3. QUERY フォーマットの発見

Accept-Query

応答フィールドでサポートされたメディアタイプを確認します。または、誤った形式を送信して

415 Unsupported Media Type

と返されるか確認することも可能です。

A.4. Content-Location および Location の使用

Content-Location: 結果を持つリソースを識別（一時的）。
Location: 次の GET リクエストで同じ結果を取得できるリソースの URI を提供します。条件付き GET (
```
If-Modified-Since
```
など) を使用すると、変更がない場合は
```
304 Not Modified
```
を返されます。

A.5. 条件付きリクエスト

同等のリソースに URI が割り当てられる場合（例：

/stored-queries/...

）、以降は

GET

で結果を取得でき、クエリコンテンツの再送信を回避できます。データ変更時には新しい結果が返されます。

A.6. その他のクエリフォーマット

JSONベースのデータベースに対して JSONPath などの形式を使用する例や、XSLT を使用してエラー情報をサマリー化する例などが示されています。

付録 B. メソッド名 'QUERY' の選択理由

IANA HTTP メソッドレジストリには、
```
safe
```
および
```
idempotent
```
プロパティを持つ既存のメソッド（
```
PROPFIND
```
,
```
REPORT
```
,
```
SEARCH
```
）が存在します。
早期段階では
```
"SEARCH"
```
が検討されましたが、最終的には "QUERY" が選ばれました。
これは、検索（Search）とデータ取得（Retrieve/Query）の概念を明確に区別するためです。

謝辞・寄稿者・著者住所

謝辞：HTTP Working グループメンバー、および特別に感謝する個人（Carsten Bormann, Mark Nottingham, Roy Fielding など）への謝意を表します。
議論の背景：Asbjørn Ulsberg 氏が 2019 年の HTTP ワークショップで再始動しました。Ashok Malhotra 氏は早期議論に参加しました。
著者：Julian Reschke, James M Snell, Mike Bishop

RFC 10008：新しい HTTP リクエストメソッド