URLのクエリ文字列は、存在するデータ形式の中でもっとも単純なものだ——key=valueのペアを&で連結しただけのリスト。しかしこの単純さは、フラットな文字列のリスト以上に複雑なものを渡したくなった瞬間、問題に変わる。
クエリ文字列が制限されている理由
クエリ文字列という形式は元々シンプルなHTMLフォームのために設計されたもので、データ型・入れ子構造・配列といった概念を一切持たない。すべてが単なるテキストであり、数値の42と文字列"42"は、コード側が明示的に解釈するまで区別できない。
配列の表現方法:Ruby on Railsの角括弧記法
日本はRuby on Railsが今なお現役で広く使われている数少ない市場の一つだ——Rubyの作者まつもとゆきひろ氏が日本人であることもあり、Cookpadをはじめ日本発のRailsプロダクションが多数存在する。Railsの背後にあるRackはtags[]=a&tags[]=bを配列として、filter[status]=activeをネストした構造としてネイティブに解釈する——これはPHPの配列パース方式と偶然にも非常によく似た挙動だ。一方でASP.NETなど別のエコシステムでは、同じキーを角括弧なしで繰り返す(tags=a&tags=b)方式を期待することが多く、クライアントとサーバーで規約が食い違うと配列データは静かに失われたり壊れたりする。
JSONがこの問題を解決する理由
JSONは数値・真偽値・nullといった型を内蔵しており、エンコーディングの取り決めなしにネストしたオブジェクトや配列を自然に表現できる。だからこそPOSTリクエストのボディでは複雑なデータを通常JSONとして送り、クエリ文字列はフィルターやページ番号のような単純でフラットなパラメータ専用として使い分けられている。
何に使うか
- バックエンドがクエリ文字列内の配列パラメータをどの形式で期待しているかを確認する。
- デバッグしやすくするため、URLパラメータをJSONに変換する。
- 複雑なデータ構造をGETパラメータで渡すべきではない理由を理解する。
URLの長さ制限
ほとんどのブラウザとサーバーはURLの長さを2000文字程度に制限しており(正確な値はブラウザやWebサーバーによって異なる)、クエリ文字列は物理的に大量のデータを運ぶのに向いていない。これも、複雑なフォームや配列データにはJSONボディを持つPOSTリクエストが標準的な選択とされ、クエリ文字列付きのGETは短くシンプルなパラメータ専用に留められている理由の一つだ。