新しい HTTP QUERY メソッド

 (kreya.app)
13 ポイント 投稿者 awbrg789 4 시간 전 | 6件のコメント | WhatsAppで共有

RFC 10008 で新たに定義された HTTP QUERY メソッドの説明

従来の RESTful API で複雑な検索を処理する際、GET と POST のどちらにも限界があったが、これを解決するため長年の議論の末に QUERY メソッドが標準化された

GET の限界

  • 複雑なフィルタや関係クエリを URL パラメータで送ると URL が過度に長くなり、ブラウザやサーバーの文字数制限にかかる可能性がある
  • 非 ASCII 文字や特殊文字はエンコードが必要なため、リクエストサイズが増加する
  • 配列やネスト構造の表現方式が標準化されていない（例: roles[]=admin vs roles=admin）
  • サーバーやミドルウェアが URL パラメータをログに記録するため、機微なデータ送信時に問題となる
  • GET にリクエストボディを送ることは仕様上明示的に禁止されてはいないが、プロキシ、ファイアウォール、ブラウザごとに処理方式が異なるため、実質的に利用できない

POST による回避策の問題

  • リクエストボディは送れるが、POST は非冪等（non-idempotent）として定義されているため、失敗時の自動リトライが安全ではない
  • プロキシやミドルウェアが読み取り専用の処理であると認識できず、自動キャッシュなどの最適化が不可能
  • 意味論的にリソース作成・処理用である POST を検索に使うのは、RESTful 設計原則に合わない

QUERY メソッド

  • GET のように安全（safe）かつ冪等（idempotent）でありながら、リクエストボディを含められる新しい HTTP メソッド
  • キャッシュ可能だが、実装時にはリクエストボディをキャッシュキーに含める必要があるため、GET よりキャッシュ実装が複雑
  • 要するに「読み取り専用リクエストで POST を置き換える」ことが中核的な目的

注意事項

  • クライアント、プロキシ、サーバーの QUERY 対応はまだ限定的で、完全なサポートまでには時間がかかる可能性がある
  • 単純な GET クエリパラメータで十分な場合は、あえて変更する必要はない
  • フィルタ済みデータの URL 共有やブックマークが必要な場合は、依然として GET が適している

関連記事

6件のコメント

 
jongyeol 2 시간 전

GET にリクエスト本文を送ることは仕様上明示的に禁止されているわけではありませんが、プロキシ／ファイアウォール／ブラウザごとに処理方法が異なるため、実質的には使用不能です。

えっと……プロキシ／ファイアウォール／ブラウザごとに、この先10年くらいは QUERY メソッドがまだ適用されないかもしれない、という点は考えなかったのでしょうか？ それとも、かなり先を見越してのことなんでしょうか。
 
tesha001 22 분 전

後者のようですね
 
click 3 시간 전

ある会社のサービスAPIがPOSTを受け付けるのに、URLパラメータも同じように付けないと動かなかった問題があったのを思い出しますね。
韓国ではPUTやDELETEですら「それ何？」というケースがかなりあるのに、QUERYまで定着するにはどれくらいかかるのか分かりません
 
savvykang 2 시간 전

???: POSTはセキュリティに良い
 
sea715 3 시간 전

??? : RESTするな、全部POSTで統一しろ
 
ultimategamer 59 분 전

RFC文書は https://datatracker.ietf.org/doc/rfc10008/ ですね。
GETにはURLが長くなるという欠点もありますが、ElasticSearchの特定の検索フィルタ結果を共有したいときのように、URLアドレスをそのまま共有できるという利点もあるように思います。

GETリクエストはブラウザのアドレスバーに入力することを前提として、暗黙的に使われている場面も多いでしょうし、定着するまでには技術的なサポート以上に多くの時間がかかりそうですね。