導入: なぜ今、fetch APIのレスポンス処理を見直すべきなのか
モダンなフロントエンド開発において、fetch APIは標準的な通信手段となりました。しかし、単にデータを取得するだけでなく、レスポンスのステータスコードに応じたエラーハンドリングや、JSON解析時の失敗をどう制御するかは、アプリケーションの堅牢性に直結します。本記事では、Response.prototype.json() を正しく使いこなし、実務でトラブルを未然に防ぐためのベストプラクティスを解説します。
基礎知識: Response.prototype.json() とは何か
fetch APIが返す Promise は、Response オブジェクトで解決されます。Response.prototype.json() は、このレスポンスボディをJSONとして読み取り、JavaScriptのオブジェクトへパースするための非同期メソッドです。
重要なポイントは、このメソッドは「HTTPエラー(404や500など)であってもJSONを解析しようとする」という点です。fetch APIはネットワークエラー以外では拒否(reject)されないため、開発者が明示的にレスポンスの成功(okプロパティ)をチェックする必要があります。
実装/解決策: 堅牢なデータ取得パターン
実務では、単に fetch して json() を呼ぶのではなく、必ずレスポンスのステータスを確認するラッパー関数を構築すべきです。以下の手順が推奨されます。
1. fetchの結果を受け取る。
2. response.ok を確認し、false であればエラーを投げる。
3. 正常であれば response.json() を呼び出す。
サンプルプログラム: 実務でそのまま使える安全なfetch関数
このコードは、エラーハンドリングとJSON解析を最適化した例です。
/
- 安全にデータを取得する汎用関数
- @param {string} url - 取得先のURL
- @returns {Promise
}
応用・注意点: 現場で陥りやすい罠
実務において注意すべき点が3つあります。
1. 空のレスポンスでクラッシュする
サーバーが 204 No Content を返した場合、response.json() は「予期せぬトークン」としてパースエラーを発生させます。レスポンスの Content-Length や status が 204 でないかを確認する処理を挟むのが安全です。
2. 二重読み取りは不可能
Response オブジェクトのボディはストリームであり、一度 json() で読み取ると消費されます。もう一度読み取ろうとするとエラーになるため、取得したデータは必ず変数に格納して使い回してください。
3. タイムアウト処理の欠如
fetch にはデフォルトでタイムアウトが存在しません。大規模なアプリでは AbortController を併用し、一定時間で通信をキャンセルする仕組みを組み込むことが、UX向上には不可欠です。