スマホ(Android)からモックAPIを叩いて動作確認する方法

公開:

この記事の英語版: English

打合せで「このAPIを呼ぶと、こういうデータが返ってきます」と見せたい。外出先で、アプリが受け取るレスポンスの形を確かめたい。バックエンドはまだできていないが、エラーのときに画面がどうなるかは先に決めておきたい——そんなとき、手元にPCがないと何もできない、ということはありません。

この記事では、ScenarioMockでモックAPIを用意し、Androidスマホのアプリ「Mobile API Tester」から叩いて動作を確かめる手順を紹介します。題材は架空のサポートチケット(問合せ)のAPIです。チケットを作って一覧で確かめ、状態を更新し、最後に401と500のエラーを再現します。

ScenarioMockが公開しているデモのモックを使うので、アカウント登録なしで、この記事の手順をそのまま試せます。

準備するもの

Mobile API Tester は、GET・POST・PUT・PATCH・DELETE・HEAD・OPTIONS を送れるRESTクライアントです。ヘッダー、クエリパラメータ、認証(Basic / Bearer)、JSONのリクエストボディを設定でき、レスポンスのステータス・所要時間・サイズ・本文・ヘッダーを確認できます。

モックAPIを用意する

公開デモを使う

この記事では、次のデモを使います。ScenarioMockの共有ギャラリーに掲載しているもので、誰でも叩けます。

項目 値
URL https://demo-mock--support-tickets.scenariomock.com
共有ページ Support Ticket API

エンドポイントは4つです。

メソッドとパス 動き
POST /tickets チケットを作る。送ったJSONに連番の id を付けて保存し、201で返す
GET /tickets チケットの一覧を返す。60秒以内の3回目だけ500を返す
GET /tickets/:id チケットを1件返す。なければ404
PATCH /tickets/:id 送った項目でチケットを更新する。なければ404

どのエンドポイントも、Authorization: Bearer <任意の値> を付けないと401を返します。トークンの値は確かめていないので、demo-token など何でもかまいません。

デモのデータは訪問者全員で共有され、6時間ごとに空に戻ります。個人情報や本物のトークンは送らないでください。送ったリクエストは、共有ページのリクエストログで誰でも見られます(Authorization の値は伏せて記録されます)。

自分のモックを作る場合

同じ構成のモックは、ScenarioMockの管理画面から作れます。

  1. ダッシュボードの「新規プロジェクト」でプロジェクトを作る。プロジェクト画面に表示される Mock URL を控える(https://<ドメイン>--<プロジェクトのslug>.scenariomock.com の形)
  2. 「エンドポイントを追加」で GET /tickets を作る
  3. エンドポイントの画面で「シナリオを追加」から Stateful Collection を選ぶ。State Key を tickets、ID生成戦略を「連番」にし、各操作のパスを /tickets と /tickets/:id に書き換える
  4. 認証のチェックを付けるなら、エンドポイントに Conditional のシナリオを足し、「Authorization ヘッダーがなければ401」のルールを作る。Conditionalは足したエンドポイントにだけ効くので、POST /tickets なども確かめたい場合は、そのエンドポイントも追加して同じシナリオを足す

Stateful Collectionを使うと、POSTで作ったデータがGETで返ってくるモックになります。作り方の詳細は、管理画面の使い方のページ(/docs)を見てください。

Mobile API Tester から GET を送る

まずはチケットの一覧を取得します。

  1. メソッドを GET にし、URLに https://demo-mock--support-tickets.scenariomock.com/tickets を入力する
  2. 認証で Bearer を選び、トークンに demo-token を入力する
  3. 送信する

Mobile API TesterでGET /ticketsを送り、200 OKと作成済みのチケット1件の配列が表示された画面

ステータスは色とアイコンで表示され、200 なら ✓ が付きます。所要時間とサイズもあわせて表示されるので、レスポンスが重すぎないかの目安にもなります。本文のJSONは整形して表示され、Raw表示に切り替えることもできます。

デモのデータは6時間ごとに空になるので、[](空の配列)が返ってくることがあります。ほかの訪問者が作ったチケットが見えることもあります。

POST で作って GET で取れることを確かめる

次に、チケットを作ります。

  1. メソッドを POST にし、URLを .../tickets にする(認証の Bearer はそのまま)
  2. リクエストボディをJSONにして、次の内容を入力する
{
  "subject": "Cannot log in to the app",
  "priority": "high",
  "status": "open",
  "customerEmail": "[email protected]"
}

JSONの整形ボタンで見やすく整えられ、構文のチェックもできます。Content-Type: application/json はボディに合わせて自動で付くので、ヘッダーを手で足す必要はありません。

  1. 送信すると、201 と、id が付いたチケットが返ってくる

Mobile API TesterでPOST /ticketsを送り、201 Createdとid "1"が付いたチケットが表示された画面

続けて、もう一度 GET /tickets を送ってください。いま作ったチケットが一覧に含まれているはずです。返ってきた id を使って GET /tickets/<id> を送れば、そのチケットだけを取得できます。

状態の更新も試せます。メソッドを PATCH にし、URLを .../tickets/<id>、ボディを {"status": "resolved"} にして送ると、status だけが変わったチケットが返ります。もう一度 GET すれば、一覧の status も変わっています。

固定のレスポンスを返すだけのモックでは、POSTしても一覧は変わりません。作る→一覧に出る→更新が反映されるという流れを確かめられるのが、データを保存する(ステートフルな)モックの利点です。アプリの「登録したら一覧に戻って表示する」画面を、バックエンドなしで確かめられます。

エラーを再現する

正常系だけでなく、エラーのときにアプリがどう振る舞うかもスマホから確かめられます。

401: トークンを外す

認証を「なし」に切り替えて、GET /tickets を送ります。

認証なしでGET /ticketsを送り、⚠のアイコン付きの401 UnauthorizedとProblem Detailsの本文が表示された画面

ステータスは 401 になり、⚠ のアイコンで表示されます。Mobile API Tester は4xxや5xxのときも本文とヘッダーを表示するので、モックが返したエラーの中身をそのまま読めます。

{
  "type": "https://api.example.com/problems/unauthorized",
  "title": "Authentication required",
  "status": 401,
  "detail": "Send an Authorization header with a Bearer token. Any token value is accepted in this demo."
}

レスポンスヘッダーには WWW-Authenticate: Bearer realm="support-tickets" が付いています。本文は RFC 9457 の Problem Details という形式です。エラーレスポンスの形をそろえたい場合は RFC 9457対応のAPIエラーレスポンス設計 で解説しています。

500: 3回目だけ失敗させる

認証を Bearer に戻し、GET /tickets を続けて3回送ります。3回目だけ 500 が返り、✕ のアイコンで表示されます。

3回目のGET /ticketsで、✕のアイコン付きの500 Internal Server ErrorとProblem Detailsの本文が表示された画面

これは ScenarioMock の Sequence シナリオで、「60秒以内の3回目だけ500を返す」と設定しているためです。回数は利用者のIPアドレスごとに数え、最初のリクエストから60秒たつと数え直します。4回目は再び 200 が返るので、「失敗したら再送する」処理の確認にも使えます。

いくつか注意があります。

どのエラーをどう確かめるかの観点は、APIエラーレスポンスのテスト設計|観点と再現方法 にまとめています。

スマホでの確認を楽にする使い方

スマホのアプリから叩いて動いても、ブラウザで動くWebアプリから呼んだときに同じように動くとは限りません。ブラウザには、ほかのドメインへのリクエストを制限するCORSという仕組みがあり、ネイティブアプリやcURLにはこの制限がないためです(下の「開発チームより」)。ScenarioMockのモックはどのOriginからのリクエストも許可しているので、ブラウザのフロントエンドから直接呼べます。

開発チームより

「curlで叩いて動いたから大丈夫」は、ブラウザから呼ぶAPIには当てはまらない——これは私たち自身がScenarioMockで経験したことです。

2026年9月、ScenarioMockの使い方を説明する文書を書くために、機能の動きを一つずつ確かめていたときのことです。モックはcurlで叩けば問題なく応答していました。ところが、ブラウザで動くフロントエンドから、JSONのボディやAuthorizationヘッダーを付けて呼ぶと、ブラウザが本番のリクエストの前に送る確認(CORSのプリフライト)の段階で止まってしまう設定になっていました。管理画面のAPI向けの「許可するOriginの一覧」が、モックにも当てはまっていたのが原因です。

curlやスマホのネイティブアプリは、CORSの制限を受けません。そのため、こうした道具で確かめている限り、この問題は見えません。いまはモックのホストだけ設定を分けて、どのOriginからでも呼べるように直しています。

スマホからの確認は手軽で、打合せや外出先では特に便利です。ただ、実際にAPIを呼ぶのがブラウザのWebアプリなら、最後はブラウザからも一度呼んで確かめることをおすすめします。

まとめ

Mobile API Tester の機能や画面は Mobile API Tester(Androidアプリ)の紹介ページ で紹介しています。モックAPIの考え方や使いどころは モックAPIとは?必要な理由から作り方、無料ツールの選び方まで を見てください。

打合せや外出先でも、スマホからそのまま叩けるモックAPIを作ってみませんか。ScenarioMockなら、POSTしたデータが返るモックやエラーを返すモックを無料で作り、URL1つで共有できます。

スマホから叩けるモックを無料で作る