GETでもPOSTでもない HTTP新メソッド「QUERY」が標準化へ：30年ぶりの新たな選択肢

GETでもPOSTでもない、第3のHTTPメソッドが標準化に進んだ。IETFが公開した「QUERY」は、検索専用のHTTPメソッドとして設計され、長年指摘されてきたURL長や検索APIの課題を解決することを目指す。新仕様の仕組みと実装への影響を読み解く。

[＠IT]

　インターネットの運用や利用に関する技術仕様の標準化を推進する国際的な任意団体Internet Engineering Task Force（以下、IETF）は2026年6月、HTTPの新たなリクエストメソッド「QUERY」の仕様を定義した技術文書「RFC 10008」を公開した。

　RFC 10008は、将来的な正式標準を目指す「Proposed Standard（標準候補）」として位置付けられており、WebブラウザやWebサーバ、APIフレームワークなどでの実装を見据えた仕様となる。

　HTTPでは長年、「GET」と「POST」という2つのメソッドがWebサービスやAPIの中心を担ってきた。しかし近年は検索条件が複雑化し、GETでもPOSTでも扱いにくいケースが増えている。QUERYは、その課題を解決するために提案された新たなHTTPメソッドだ。

RFC 10008とは何か？

　RFC（Request for Comments）とは、インターネットで利用される通信技術やプロトコルの仕様をまとめた公開文書だ。HTTPやDNS、SMTP、TCP/IPなど、現在のインターネットを支える多くの技術はRFCとして公開されている。名前に「Comments」とあるが、現在では実質的にインターネット技術の設計書や仕様書として利用されている。

　今回公開されたRFC 10008は、HTTPに新たなリクエストメソッド「QUERY」を追加する仕様を定義した文書である。

　また、RFC 10008は「Proposed Standard」として公開された。これは、IETFが「実装を進めてもよい成熟度に達した」と判断した標準候補を意味する。まだ最終的なインターネット標準（Internet Standard）ではないものの、WebブラウザやWebサーバ、アプリケーション開発者が実装し、広く利用されることを想定した段階にある。

　つまりRFC 10008は「こんな仕組みを提案します」というアイデア段階ではなく、「これから実装・普及が進むことを期待する仕様書」と位置付けられる。

なぜGETとPOSTだけでは足りなくなったのか？

　HTTPにはクライアントがサーバに要求を送る方法を示す「リクエストメソッド」がある。最もよく使われるのがGETとPOSTだ。

　GETは、Webページの表示や検索結果の取得など、データを取得する処理で利用される。一方、POSTは会員登録や商品の購入、ファイルのアップロードなど、サーバ側のデータを追加・更新する処理で使われる。

　しかし近年は、APIを利用したサービスが急速に普及した。APIでは「東京都内の売上上位100店舗を抽出する」「条件に一致するログを検索する」といった複雑な検索処理を実行する機会が増えている。

　こうした検索処理では、GETとPOST双方に課題があった。

　例えばGETでは、検索条件が増えるほどURLは長くなる。ネットワーク機器やWebサーバによってはURL長に制限があり、非常に複雑な検索条件ではエラーになる可能性がある。

　さらに、URLはWebブラウザの履歴やブックマーク、アクセスログ、リバースプロキシやロードバランサーなどのログに残りやすい。そのため検索条件に顧客IDや社内システム名、機密性の高い情報が含まれる場合は、意図せず情報が記録されるリスクがある。

　一方、POSTでは検索条件をHTTP本文に格納できるため、URL長を気にする必要はない。しかしPOSTは、本来データの登録や更新にも使われるメソッドだ。そのため、POSTを見ただけでは「検索なのか」「データを書き換える処理なのか」が分からない。

　HTTPでは、この違いは非常に重要だ。

　検索のようにデータを変更しない処理なら、通信障害が発生しても同じリクエストを再送しやすい。一方、購入処理や送金処理を再送すると、二重注文や二重決済が発生する恐れがある。

　つまり、「本文を利用して複雑な検索を送りたいが、検索専用であることもHTTPに伝えたい」というニーズが以前から存在していたのである。

GETとPOSTの“いいとこ取り”を目指したQUERY

　QUERYはこの問題を解決するために設計された。QUERYでは、検索条件をHTTP本文に格納する。そのため、GETのようにURL長を気にする必要がなく、検索条件をURLに書き出す必要もない。

　それと同時に「このリクエストは検索専用であり、サーバ側のデータを変更しない」という意味をHTTPに明確に伝えられる。

　RFCではQUERYを「安全」かつ「冪等（べきとう）」（※）なHTTPメソッドとして定義している。

（※）同じ操作を何回繰り返しても常に同じ結果が得られる性質

　この性質をHTTPそのものに明示できる点が、POSTとの大きな違いだ。つまりQUERYは、POSTと同様に本文に検索条件を書け、GETと同じように検索専用で安全な処理であることを示せる双方の長所を組み合わせた、新しいHTTPメソッドといえる。

QUERYはどのように動作するのか

　QUERYでは検索条件をHTTP本文に記述する。どのような形式で検索条件を書くかは、「Content-Type」と呼ばれるHTTPヘッダで指定する。HTTPヘッダとは、リクエストやレスポンスに付加される補足情報で、Content-TypeにはJSONやSQLなど検索条件のデータ形式を記載する。

　サーバはContent-Typeを基に検索条件を解釈し、検索が成功すれば「200 OK」を返す。対応していないデータ形式には「415 Unsupported Media Type」、検索条件を処理できない場合には「422 Unprocessable Content」など、既存のHTTPステータスコードを利用する。

　またRFCでは、「Accept-Query」という新しいHTTPヘッダも定義した。これはサーバがQUERYに対応していることや、利用可能な検索形式をクライアントに通知するための仕組みだ。対応状況は、HTTPのOPTIONSメソッドへの応答でも確認できる。

キャッシュとセキュリティで注意すべき点

　QUERYの応答はキャッシュにも対応する。ただしGETでは通常、URIを基にキャッシュを識別できるが、QUERYでは検索条件が本文に含まれるため、キャッシュキーにも本文を含める必要がある。そのため、GETより実装は複雑になる。

　RFCは、検索条件の表記だけを統一する「正規化」は認める一方、誤った正規化によって異なる検索結果を同じものとして扱わないよう注意を促している。

　セキュリティ面では、検索条件をURLではなく本文に格納することで、Webブラウザの履歴やアクセスログなどに機密情報が残る可能性を低減できる点を利点として挙げた。ただし、検索結果を表す一時的なURIを発行する場合は、検索条件に含まれる機密情報をURIに含めないよう求めている。

　また、Webブラウザから異なるWebサイトにアクセスする際の仕組みである「Cross-Origin Resource Sharing」（CORS）では、QUERYはセーフリスト対象のHTTPメソッドではない。そのため、利用前にはサーバがQUERYを受け付けるかどうか確認する「プリフライト要求」が必要になる。

API設計へ影響を与える可能性も

　RFC 10008は、現時点では標準化プロセスの途中段階であるProposed Standardに位置付けられており、すぐにWebブラウザやWebサーバで広く利用できるわけではない。

　しかしHTTPサーバやAPIフレームワークなどが今後対応を進めれば、これまでPOSTで実装されることが多かった複雑な検索処理に、新たな選択肢が生まれる可能性がある。

　HTTPでは長年、GETとPOSTが中心的な役割を担ってきた。QUERYが広く普及するかどうかは今後の実装次第だが、API開発やWebサービス設計の在り方に影響を与える可能性がある新たなHTTPメソッドとして注目されそうだ。