概要

• RFC 10008 で新たに定義された HTTP QUERYメソッド の登場背景
• 従来の GET/POST の課題とQUERY導入の意義
• QUERYの 技術的特徴 と使い方の注意点
• 現状の対応状況 や今後の普及見通し
• QUERY導入時の 実装上のポイント と結論

RESTful APIのHTTPメソッドとQUERY登場の背景

• RESTful APIでは、 GET でデータ取得、 POST でリソース作成、 PUT で更新など、 HTTPメソッド が操作意図を示す役割
• HTTPメソッドは単なる 文字列 だが、GETやPOSTには RFCや実装依存の振る舞い が多数存在
  • 例：ブラウザはアドレス入力やブックマークでGETを自動送信
  • 標準HTTPフォームではGET/POSTのみ利用可能
  • 多くのプロキシ・ファイアウォール・Webサーバーは標準メソッドのみ許可
• 既存メソッドで十分と思われていたが、 複雑な検索クエリ で限界が顕在化

GETによるクエリの課題

• 単純なフィルタ はGETのクエリパラメータで対応可能
  • 例：/api/v1/users?role=admin&status=active&sort=desc
• 複雑なリレーション・ネスト・高度なロジックでは URLが長大化・可読性低下・文字数制限超過 のリスク
  • 非ASCIIや特殊文字のエンコードでリクエストサイズ増大
  • サーバーやミドルウェアでの リクエストパラメータのログ記録 が問題になる場合も
  • 配列や深いネストの表現が 実装依存・仕様が曖昧
• GETで リクエストボディ送信 は理論上可能だが、HTTP RFCでは非推奨
  • 実際には多くのクライアント・プロキシ・WebサーバーがGETボディを 無視・拒否・独自解釈
  • そのため、GETボディ利用は 非推奨 で運用上の問題が多発

POSTによるクエリのワークアラウンドと課題

• GETでボディが使えないため、 POSTでリクエストボディ を送信する方法が一般的
• しかし、POSTは 非冪等・リソース作成/処理用 の意味合い
  • 冪等性が担保できず、 自動リトライ時の副作用 リスク
  • ミドルウェアやプロキシが GETのみ自動キャッシュ する仕様のため、POSTではキャッシュ不可
  • 読み取り専用操作 であることを自動判別できず、設計上の違和感

QUERYメソッドの登場と特徴

• こうした課題を受けて、 QUERYメソッド がRFC 10008で正式に定義
• QUERYは GETに似ているが、リクエストボディ送信が可能
  • 安全かつ冪等 であることが前提
  • キャッシュ可能 （ただし、キャッシュキーにリクエストボディを含める必要）
• 複雑な検索クエリ に最適なHTTPメソッドとして位置付け

QUERY利用時の注意点・課題

• QUERYを すぐに全面採用 するのは時期尚早
  • 現時点での 対応クライアント・プロキシ・Webサーバーは限定的
    • 例：Kreyaは1.20でQUERY対応済みだが、他は未対応多数
  • GETのURLパラメータによるクエリは 引き続き有効
• リンク共有やブックマーク が必要な場合はGET推奨
  • QUERYはリクエストボディ利用のため、URL共有不可
• QUERYの キャッシュ実装は難易度が高い
  • リクエストボディをキャッシュキーに含める必要があるため

結論

• HTTP QUERYは、読み取り専用の複雑なリクエストにおいてPOSTの置き換えとなる新メソッド
• 普及までに時間を要するが、 GETで対応困難な場合の選択肢 として検討価値あり
• 利用時は 互換性・キャッシュ・共有性 に十分注意し、 十分なテスト を推奨