オーバーフェッチは、本当は使わないデータまで API から一緒に取ってきてしまう状態です。
初心者向けには、名前だけ欲しいのに、住所も履歴も画像URLも全部返ってくる 状態と考えると分かりやすいです。
どんな場面で起きるか
- 一覧画面で3項目しか表示しないのに、詳細用の30項目を返すエンドポイントを使い回している
- 詳細APIを一覧でも使っており、1件あたりのレスポンスが数十KBある
- 関連データ（部署、タグ、画像）を常に埋め込んで返している
何が問題になるか
- 通信量が増える（モバイル回線やデータ量制限のある環境で効いてくる）
- サーバー側で不要なテーブルまで結合し、DBの負荷と応答時間が伸びる
- 巨大なJSONのパースでフロント側のメモリと描画も重くなる
- 使っていない個人情報まで返してしまい、情報の露出範囲が広がる
最後の点は見落とされがちですが、画面に出していない＝安全 ではありません。レスポンスに入っていれば開発者ツールから見えます。
対処の方向
- GraphQL のように、クライアントが欲しい項目だけ指定できる仕組みを使う
- REST API でも
?fields=id,nameのような項目指定や、一覧用と詳細用でエンドポイントを分ける設計にする - 画面ごとに必要な形へ整えて返す層（BFF）を挟む
アンダーフェッチとのトレードオフ
アンダーフェッチ（足りなくて何度も呼ぶ）とは逆向きの問題で、片方を潰すともう片方が出やすくなります。
レスポンスを削れば往復が増え、まとめて返せば無駄が増える、という綱引きです。実務では 画面の主要ケースで1〜2往復に収まり、無駄な項目が半分を超えない あたりを落としどころにします。
注意点
GraphQL に変えれば自動で解決、というわけではありません。 クライアント側の取りすぎは減っても、サーバー側でリゾルバが1件ずつDBを叩く N+1 が起きれば、遅さの原因が移動しただけになります。
あわせて見たい用語
どちらの方式を選ぶかは GraphQLとREST APIの違いは？ で整理しています。