JSONTech
ツール:JSON フォーマッターJSON バリデーターJSON ビューアJSON 比較JSON 修復JWT デコーダーJSONPath テスター

How to Test REST APIs in Your Browser — A Developer's Guide

Learn how to test REST APIs in your browser, when CORS blocks direct requests, and when to switch to proxy-based testing. Covers HTTP methods, headers, auth, status codes, and hands-on examples.

JSONTech チームMarch 25, 202610 min read

APIテストとは

現代のWebアプリやモバイルアプリは、すべてAPIの上で動いています。Twitterのタイムラインを開く、Amazonで注文する、スマートフォンで天気を確認する——その裏ではAPI呼び出しが行われています。APIテストとは、そうしたエンドポイントにリクエストを送り、レスポンスが正しいかを検証する実践です。適切なステータスコード、期待どおりのデータ構造、妥当なパフォーマンスを確認します。

UIテストとは異なり、APIテストはインターフェースの下の層を対象にします。バグを早い段階で見つけられ、実行も速く、ブラウザのクリックでは再現しにくいシナリオもカバーできます。自前のAPIを作る場合でもサードパーティのサービスと連携する場合でも、エンドポイントを素早くテストできることは、開発者としての基本的なスキルです。

HTTPメソッドの説明

REST APIでは、リソースに対して行う操作を示すために、標準のHTTPメソッドを使います。要点は次のとおりです。

メソッド目的ボディの有無
GETリソースまたはコレクションを取得するなし
POST新しいリソースを作成するあり
PUTリソースを丸ごと置き換えるあり
PATCHリソースを部分的に更新するあり
DELETEリソースを削除するほぼなし

重要な違い： PUTはリソース全体を置き換えます——省略したフィールドは削除されます。PATCHはリクエストボディに含めたフィールドだけを更新します。更新を受け付けるAPIの多くは、部分的な変更にはPATCH、完全な置き換えにはPUTを使います。

ブラウザでAPIをテストする

Postmanを入れたり、cURLのオプションを暗記したりしなくてもAPIをテストできます。JSONTech.netのAPI Explorerなら、CORSが有効なAPIにはブラウザモードで送信でき、ブラウザにブロックされた場合はプロキシモードへ切り替えられます。手順は次のとおりです。

  1. API Explorerを開きます。
  2. ドロップダウンからHTTPメソッド（GET、POST、PUT、PATCH、DELETE）を選びます。
  3. エンドポイントのURLを入力します。例：https://jsonplaceholder.typicode.com/posts/1
  4. 必要なヘッダー（Content-TypeやAuthorizationなど）を追加します。
  5. ボディが必要なメソッド（POST、PUT、PATCH）の場合は、ボディエディタにJSONペイロードを入力します。
  6. Sendを押し、レスポンス——ステータスコード、ヘッダー、整形されたJSONボディ——を確認します。

ブラウザがCORSエラーを表示したら、API Explorerをプロキシモードに切り替えてください。そうすると実際のリクエストはJSONTechのエッジ基盤を経由して送られ、ページを離れずにテストを続けられます。

例：投稿の取得

GET https://jsonplaceholder.typicode.com/posts/1

Response (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\\nsuscipit recusandae consequuntur..."
}

例：投稿の作成

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Response (201 Created):
{
  "id": 101,
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

リクエストヘッダーを理解する

ヘッダーにはリクエストに関するメタデータが載ります。サーバーに、どの形式を期待しているか、誰が送っているか、接続をどう扱うかを伝えます。よく使うものは次のとおりです。

ヘッダー目的値の例
Content-Typeリクエストボディの形式application/json
Acceptレスポンスで欲しい形式application/json
Authorization認証用の資格情報Bearer eyJhbGciOi...
Cache-Controlキャッシュに関する指示no-cache
User-Agentクライアントアプリを識別するMyApp/1.0

POST/PUTリクエストでContent-Type: application/jsonを付け忘れると、APIが400 Bad Requestを返す代表的な原因のひとつになります。これがないと、サーバーはボディの解釈方法が分かりません。

認証の方法

本番のAPIの多くは認証を要求します。よく出会うパターンは主に次の3つです。

Bearerトークン（JWT）

現代のAPIで最も一般的な方法です。Authorizationヘッダーにトークンを含めます。

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

Basic認証

ユーザー名とパスワードをBase64でエンコードした文字列にします。シンプルですが、HTTPS上でのみ安全です。

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

APIキー

固定のキーをカスタムヘッダーやクエリパラメータで渡すAPIもあります。

// As a header
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// As a query parameter
GET https://api.example.com/data?api_key=sk_live_abc123def456

APIレスポンスの読み方

リクエストを送ると、レスポンスに結果がそのまま表れます。読むべきは次の3つです。ステータスコード、レスポンスヘッダー、ボディです。

ステータスコード

コード意味いつ見るか
200OK成功したGET、PUT、PATCH、DELETE
201Createdリソースを作成した成功したPOST
400Bad RequestJSONが不正、必須フィールド不足、型の誤り
401Unauthorized認証トークンがない、または期限切れ
403Forbidden認証は有効だが権限が足りない
404Not Foundエンドポイントまたはリソースが存在しない
500Internal Server Errorサーバー側で何かが壊れた

レスポンスヘッダー

Content-Type（レスポンス形式の確認）、X-RateLimit-Remaining（残りリクエスト数）、Retry-After（レート制限後に再試行するまでの時間）などに注意します。

JSONボディ

レスポンスボディにデータが入ります。設計のよいAPIは、一貫した構造で包みます。

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

問題が起きた場合は、データオブジェクトの代わりにエラーオブジェクトが返ります。必ず先にステータスコードを確認し、その結果に合わせてボディを解釈します。

CORSとは、なぜエラーが出るのか

Cross-Origin Resource Sharing（CORS）は、ブラウザのセキュリティ機構です。localhost:3000上のJavaScriptがapi.example.comのAPIを呼び出そうとすると、サーバーがCORSヘッダーで明示的に許可しない限り、ブラウザはリクエストをブロックします。

典型的なエラーは次のような表示です。

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

これはコードのバグではなく、ブラウザがセキュリティを適用している状態です。対処はサーバー側で行う必要があります。よく使われる回避策は次のとおりです。

  • APIの運用者に依頼し、自分のオリジンをAccess-Control-Allow-Originに追加してもらう。
  • プロキシを使う——Next.jsのAPIルートやシンプルなExpressサーバーなど、自前のバックエンド経由でリクエストを流し、クロスオリジンの制限そのものを避ける。
  • プロキシ機能付きのブラウザ向けツールを使う——API Explorerのように、公開APIではブラウザモードから始め、必要になったらJSONTechがテスト用にリクエストを中継するプロキシモードへ切り替えられるものです。

CORSの影響を受けるのはブラウザだけです。cURL、Postman、サーバー側のコードなどはCORSの制限の対象外で、ブラウザのサンドボックス内ではありません。

APIテストでよくある失敗

初心者から、慣れないAPIに触れる経験豊富なエンジニアまで、つまずきやすい点は次のとおりです。

  1. Content-Typeヘッダーを忘れる。 JSONボディをContent-Type: application/jsonなしで送ると、多くのサーバーがリクエストを拒否したり、誤って解釈したりします。
  2. POSTのつもりでGETを使う。 GETリクエストにボディを付けてはいけません。データを送るならPOST、PUT、またはPATCHが必要です。
  3. ステータスコードを無視する。 ボディにエラーメッセージが入っていても200なら成功ではありません。実際のHTTPステータスコードを必ず確認します。
  4. 資格情報をURLに直書きする。 ヘッダーで渡せるなら、APIキーやトークンをクエリ文字列に入れないでください——URLはサーバーログ、ブラウザ履歴、Refererヘッダーに残ります。
  5. 正常系だけをテストする。 不正なJSON、空のボディ、必須フィールドの欠落、無効なトークンなども送り、APIがエラーをどう扱うか確認します。
  6. レート制限を確認しない。 多くのAPIは上限超過で429を返します。X-RateLimit-Remainingヘッダーを先回りして確認します。
  7. CORSエラーをサーバーエラーと混同する。 CORSエラーはブラウザがリクエストをブロックした状態です——サーバーは正常に応答していても、ブラウザが結果を見せてくれないことがあります。

自分で試す

APIをテストしてみますか？ API Explorerを開き、https://jsonplaceholder.typicode.com/users/1へGETリクエストを送ってみてください。ブラウザを離れずに、ステータスコード、ヘッダー、整形されたJSONボディをまとめて確認でき、別のAPIがCORSでブロックされた場合はプロキシモードで再試行できます。

ダウンロードも、登録も、設定も不要です。メソッドを選び、URLを入力し、Sendを押すだけです。

関連ツール

LLM JSON Output Validator

Repair and validate model JSON output against a schema

JSON フォーマッター

インデント設定で JSON を整形

MCP Tool Schema Validator

Validate MCP tool definitions and verify `inputSchema` before deployment

JWT デコーダー

JWT のヘッダー・ペイロード・有効期限を表示

← ガイド一覧に戻る