【要約】なぜ並び替え条件（order）はリクエストボディではなくクエリパラメータに載せるべきなのか [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
API設計者が、複雑なソート条件を送信するために、GETリクエストのボディに条件を含めるべきか迷う場面がある。ボディを使用すると、以下の問題が発生する。
- ・URLが同一になり、CloudflareやNginx等のインフラによるキャッシュが機能しない。
- ・axiosやfetch等のライブラリ、WebサーバーによってGETのボディが無視される。
- ・URLに状態が含まれないため、検索結果の共有やブラウザの履歴管理が困難になる。
// Approach
設計者は、データの役割とWebの仕組みに基づき、ソート条件をクエリパラメータに配置する手法を採用する。具体的な手順は以下の通りである。
- ・データの役割を分離する。ボディはリソース変更用、パラメータは取得条件用と定義する。
- ・URLをキャッシュキーとして活用する。条件をURLに含め、インフラでのキャッシュ制御を可能にする。
- ・RESTの原則を遵守する。GETの安全性と冪等性を確保し、相互運用性を高める。
- ・フロントエンドの状態をURLに反映する。SPAにおいて、リロードや履歴遷移時の状態復元を容易にする。
// Result
設計者が標準的なRESTful設計に従うことで、システム全体のパフォーマンスと利便性が向上する。具体的な成果は以下の通りである。
- ・インフラ層でのキャッシュヒット率が向上し、サーバー負荷が軽減される。
- ・フロントエンド開発において、URL共有やブラウザの「戻る」機能が自然に実装できる。
- ・ライブラリやサーバー間の互換性問題による、予期せぬバグを未然に防げる。
Senior Engineer Insight
> 本記事の指摘は、大規模システムを運用する上で極めて重要である。特に、CDNやプロキシによるキャッシュの活用は、レイテンシ削減とコスト抑制の要だ。ボディに条件を隠蔽する設計は、インフラの恩恵を放棄する行為に等しい。また、フロントエンドのUXを考慮した設計は、開発効率とユーザー体験の両面で不可欠である。基本に忠実な設計こそが、スケーラビリティを担保する。