HTTP についに「ボディを持てる安全なメソッド」QUERY が来た

検索エンドポイントは二つの悪い選択肢に挟まれたままでした。GET は複雑なクエリを表現できず、POST は意味論を間違えている。

IETF の HTTP ワーキンググループは 2025 年 11 月に草案（draft-ietf-httpbis-safe-method-w-body-14）を公開し、新しいメソッド QUERY を定義しました。一行でまとめると：

QUERY は、対象リソースに安全かつ冪等な方法で内容を処理させ、その結果を返させる。POST に似ているが、部分的な状態変化を気にせず自動的に再送・再開できる。

問題：クエリを URL に押し込む

GET の意味論は正しい。安全で冪等で、キャッシュでき、プロキシが自由に再試行できる。ただしパラメータは URL にしか置けない：

十数個のフィルタを持つ検索はあっさり数千文字になり、各種の 8KB 上限に当たる
URL はアクセスログ、Referer、ブラウザ履歴に残る。検索条件には残したくないものがよく入っている
入れ子構造（グラフクエリ、真偽式の木）はクエリ文字列に潰した時点で読めなくなる

標準の答えは「なら POST を使え」でした。しかし POST の意味は「このリクエストは状態を変えうる」なので：

プロキシ、CDN、クライアントの HTTP ライブラリは既定で再試行しない。一度の通信の乱れが人間の再クリックを意味する
キャッシュ層はキャッシュしてよいか判断できない
冪等な読み取りが、語彙が足りないというだけの理由で非冪等に分類される

QUERY が埋めるもの

草案は範囲について控えめです。新しい能力ではなく、ボディを持つクエリに意味論的に正しいメソッドを与えるもの。

	GET	POST	QUERY
リクエストボディ	持つべきでない	あり	あり
安全（状態を変えない）	はい	いいえ	はい
冪等	はい	いいえ	はい
自動再送してよい	はい	いいえ	はい

最後の二行が、中間層が再試行してよいかを判断する唯一の根拠です。QUERY はそれを取り戻しつつ、ボディを保持します。

議論は ietf-http-wg@w3.org のメーリングリストで行われ、ソースと issue は httpwg/http-extensions リポジトリの query-method ラベルにあります。この版は 2026 年 5 月 22 日に失効します。つまりまだ動いているので、これに合わせて本番コードを書くべきではありません。

誰が本当に必要としているか

検索サービス。 Elasticsearch の _search は何年も前から GET にボディを載せることを許しています。非標準の、全員が暗黙に合意している回避策です。動きますが、厳密に規格に従う中間層がボディを落とす可能性は残ります。QUERY はこの取り決めを正規のものにします。

GraphQL。 クエリ自体が大きくなりうるので常に POST です。GraphQL には mutation もあるので全体を置き換えることはできませんが、読み取り専用の部分なら置き換えられます。そしてそこが最もトラフィックを運ぶ部分です。

あらゆる RPC 風の読み取りエンドポイント。 引数が JSON を必要とするほど構造化されていて、操作が読み取り専用なら、POST は嘘をついています。

摩擦は現実にある

意味論が正しいからといって明日使えるわけではありません。三つの障害：

中間層がメソッドを認識する必要がある。 古いプロキシ、WAF、一部の CDN は未知のメソッドに 405 を返します。エンドポイントの意味論が正しいからと例外を作ってはくれません。
CORS プリフライトが発生する。 QUERY は単純メソッドではないので、クロスオリジンでは毎回 OPTIONS が一回増えます。
ブラウザとクライアントライブラリの対応は一様でない。 fetch は任意のメソッドを通しますが、その上のラッパー（axios、requests、Go の http パッケージ）は非標準メソッドを同じようには扱いません。

私の結論

QUERY の価値は、新しいことを可能にすることではなく、既にある慣行が暗黙の合意に依存するのをやめさせることにあります。

今日、公開 API の唯一の入口にするつもりはありません。405 のリスクは現実です。ただし社内サービス間や、両端と中間を自分で握れる場所では POST より正直です。

注目すべきは二つ。草案が RFC になること、そして主要なリバースプロキシが既定で通すようになること。それまでは、急いで採用するより「知っている」状態のほうが得です。