正気を失わずにAPIレスポンスを読む

APIエンドポイントを叩きます。レスポンスが返ってきます。こんな感じです：

{"users":[{"id":1,"name":"John","email":"john@example.com","settings":{"notifications":true,"theme":"dark","language":"en"}},{"id":2,"name":"Jane","email":"jane@example.com","settings":{"notifications":false,"theme":"light","language":"es"}}],"meta":{"total":2,"page":1}}

必要なフィールドを見つけられたら幸運です。

これがAPIデバッグの90%がこんな感じです。minifyされたJSON、改行なし、すべてが詰め込まれています。技術的には正しい。でも読めません。

ただフォーマットすればいい

その文字の壁を取って、JSONフォーマッターに貼り付けると、突然：

{
  "users": [
    {
      "id": 1,
      "name": "John",
      "email": "john@example.com",
      "settings": {
        "notifications": true,
        "theme": "dark",
        "language": "en"
      }
    }
  ]
}

同じデータ。実際に読める。構造が見え、ネストされたフィールドを見つけ、欠落値を発見できます。

よくあるデバッグシナリオ

「APIがエラーを返すけど理由が分からない」

エラーレスポンスをフォーマットしましょう。多くの場合、ネストされた message や details フィールドが埋もれていて、何が間違ったかを正確に説明しています。minify版では見えなかっただけです。

「2つのレスポンスを比較する必要がある」

両方をフォーマットして、diffツールを使いましょう。minifyされたJSONはdiffが不可能——改行が違うのですべてが変更されたと表示されます。

「これは有効なJSONなのか？」

フォーマッターに貼り付けましょう。無効なら、問題を指し示すエラーが出ます。カンマの欠落、余分な括弧、エスケープされていない引用符——フォーマッターが教えてくれます。

JWTを扱う

JWT（JSON Web Token）はただのbase64エンコードされたJSONです。こんなものを見た時：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

これは暗号化されていません。ただエンコードされているだけ。デコードすれば実際のペイロードが見えます——ユーザーID、有効期限、権限、トークンに含まれるあらゆるもの。

認証問題のデバッグに便利です。「なぜ403が出るの？」トークンをデコード、期限切れかチェック、クレームが期待と一致するか確認。

APIレスポンスのBase64

時々APIはbase64エンコードされたデータを返します。ファイル内容、画像、暗号化されたブロブ。実際に中身を見る必要があるなら、デコードしましょう。

よく見かけるのは：

• メールAPI（添付ファイルがbase64エンコードされてくる）
• 画像アップロード（データURIはbase64）
• レガシーSOAPサービス（SOAPだから）

API作業のコツ

ブラウザ開発ツールを使う。 Networkタブがリクエストとレスポンスを表示。ほとんどのブラウザはJSONレスポンスを自動でpretty-printできます。

例のレスポンスを保存。 APIが正しく動いた時、フォーマットされたコピーを保存。壊れた時、動作版と比較できます。

content typeをチェック。 JSONに見えるものが実際はJSONを含む文字列であることも。2回パースが必要かもしれません。

エンコーディング問題に注意。 Unicode文字は問題を起こすことがあります。\u0000 コードが見えたら、それはエスケープされたUnicode——通常は問題ないですが、時々上流のエンコーディング問題を示します。

---

APIデバッグはほとんどデータを明確に見ることです。JSONをフォーマットし、トークンをデコードすれば、minifyされたブロブを凝視する時間が減ります。