APIが200なのにJSONを読めない？Content-Typeと本文を先に確かめよう

APIの通信は200なのに、JSONの解析で失敗した。成功の番号だけでなく、本当に期待したデータが返っているかを確認しよう。

この記事は、WebのAPIから受け取る応答の読み分け。実際の認証情報を送る練習はせず、ローカルの小さな再現サーバーと架空の応答で整理するよ。

HTTP番号とデータ形式は別

HTTPのステータスは要求への応答の状態。Content-Typeは、本文をどういう種類として扱うかを伝えるヘッダーだよ。

HTTP/1.1 200 OK
Content-Type: application/json

{"ready": true}

この例なら、JSONというデータ形式の本文を返している。一方、200でtext/htmlが返り、本文がログイン画面になっている場合もある。番号が200だからJSONとして読めるとは限らないんだ。

よくある三つのずれ

Content-TypeがJSONでも、構文として正しい保証ではない。逆に、JSONとして解析できたことだけで、業務処理が成功したとも言えないよ。

どの段階で読むかを決める

まず応答番号と種類を読み、仕様に合う本文の読み方を選ぶ。エラー時のJSONも読む設計なら、正常なデータと区別する。内容の型や必要な項目の確認も、その次に必要だよ。

ブラウザの開発者ツールならNetworkで対象の要求を選び、HeadersとResponse、転送後の最終URLなどを見る。Cookieや認証用の値は、そのまま人へ渡さないようにしよう。

小さな再現で比べたこと

編集部では、ローカルで200のJSON、200のHTML、JSON指定の不正な本文、503のJSONを返す入口を用意した。JSONとして解析できるかと、HTTPの成功かが別の結果になることを確認している。

これはログイン切れが必ず原因だと示す実験ではないよ。実際の応答を読んで、どこで期待とずれたかを確かめるための例なんだ。

空の成功応答は204、データ自体の確認はJSONの構文・型・必須項目へ。

参照した公式資料

• MDN：Content-Type
• MDN：Response.json

確認日：2026年10月24日。