ETEAO
生産性

    ツール名・説明・キーワードで検索。↑↓で移動、Enterで開く、Escで閉じる。

    APIレスポンスモック生成ツール

    フィールドと応答形式を選んでモックAPIレスポンスJSONを生成

    クイックスタート:
    リソースのフィールド

    APIレスポンスモック生成ツールについて

    バックエンドがまだない、あるいはあっても「空の一覧」「最終ページ」「422エラー」を狙って返させるのが難しい。そういうときフロントエンドは偽のレスポンスで先に画面を作ります。このツールはフィールド一覧と「エンベロープ(外側の形)」を選ぶと、その形のレスポンスJSONを出力します。形は配列のみ、dataラッパー、ページネーション(meta・links付き)、単一リソース、JSON:API、エラーの6種類です。

    シードを入れると mulberry32 という小さな乱数生成器が同じ順序で値を引くので、毎回同じレスポンスになります。日付も現在時刻ではなく 2024-01-01(UTC)を基準にその前の5年(2019〜2023年)の範囲で作るため、スナップショットテストに入れても翌日に壊れません。過去方向にだけ選ぶので登録日が未来になることはありませんが、「直近7日」のように今日を基準に絞り込む画面には該当データが出ない点に注意してください。

    モックで確かめられること、確かめられないこと

    モックで分かるのは「この形のデータを受け取ったとき画面が正しく描けるか」です。スピナーが止まるか、links.next が null のとき「次へ」が無効になるか、長い名前が折り返されるか、といった点です。

    分からないのは「本物のサーバーが本当にこの形で返すか」です。モックは自分が想像したAPIなので、サーバー側が user_name を username に変えてもモックを使ったテストは通り続けます。この隙間を埋めるのがコントラクトテストです。Pact のドキュメントは、各アプリケーションを個別に検査し、送受信するメッセージが「契約」に記された共通理解に合っているかを確かめる手法だと説明しています。コンシューマー側のテスト実行中に契約ファイルが生成され、プロバイダー側がそれを自分のコードで再生して検証します。

    実務では使い分けます。画面を早く作り、境界状態を再現するにはこうしたモック、リリース前のずれ検出にはコントラクトテストや OpenAPI スキーマ検証です。

    ページネーションの数値の決まり方

    total_pages は total ÷ per_page の切り上げで、最小は1です。現在ページに入る件数は total − (page − 1) × per_page を 0〜per_page に収めた値です。id はコレクション全体の通し番号なので、1ページ10件の3ページ目は21番から始まります。total を0にすると data が空配列、total_pages が1のレスポンスになり、「該当なし」画面の確認に使えます。

    最終ページより大きい page を指定すると、空配列で next が null になります。実際のAPIではこの場合に空ページを返すか404を返すかが分かれるので、接続先の挙動を先に確認しておくと安心です。

    エラーレスポンスには標準がある

    このツールのエラー形式は { error: { status, code, message, request_id } } で、422 のときは details 配列が付きます。よく見かける形ですが標準ではありません。HTTP API のエラー形式の標準は RFC 9457(Problem Details)で、メディアタイプ application/problem+json と、type・title・status・detail・instance のメンバーを使います。type がなければ about:blank とみなされます。

    また RFC 9110 で 422 の名称は「Unprocessable Content」に変わり(旧名は Unprocessable Entity)、このツールは新しい名称を出力します。理由フレーズはクライアントが解釈しない部分なので、サーバーが旧名を送っても動作には影響しません。エラー本文の code 値(unprocessable_entity)は API ごとの慣例文字列なのでそのままにしています。

    JSON:API モードの違い

    各レコードは { type, id, attributes } に包まれ、id は attributes から外されて文字列になります。仕様がリソースIDを文字列と定めているためです。最上位には jsonapi.version(1.1)、meta、links が付きます。relationships と included は生成しないので、関連データを表示する画面では手で補ってください。

    例

    23件中3ページ目(1ページ10件)、シード42

    入力
    スタイル: ページネーション / フィールド: id(id)、name(fullName)、status(pick: active,pending)/ total 23、page 3、per_page 10、resource users
    結果
    data 3件(id 21・22・23 — Noah Hernandez、Emma Jones、Michael Anderson)、meta: {"page":3,"per_page":10,"total":23,"total_pages":3,"count":3}、links.next: null

    23 ÷ 10 を切り上げて3ページ、最終ページには3件だけ残ります。next が null なので「次へ」ボタンの無効化テストにそのまま使えます。

    422 エラー+HTTPヘッダー付き

    入力
    スタイル: エラー / ステータス 422 / HTTPヘッダーを含める / シード7
    結果
    HTTP/1.1 422 Unprocessable Content Content-Type: application/json; charset=utf-8 ... {"error":{"status":422,"code":"unprocessable_entity",...,"details":[{"field":"id","issue":"is invalid"}]}}

    details の field にはスキーマのうち id 以外のフィールドがシードに応じて1つ入り、issue は型に合った文言になります(email なら must be a valid email address)。この例のようにフィールドが id だけなら id と is invalid です。エラースタイルで選べるステータスは 4xx・5xx だけです。入力欄の横にエラーを出す画面なら、field を実際の入力項目名に合わせてください。

    使い方

    1. フィールドを追加して型を選びます。integer・float は「最小,最大」、pick はカンマ区切りの候補をパラメータに入れます。
    2. スタイルと total・page・per_page を決めます。エラーならステータスコードとメッセージを選びます。
    3. 再現が必要ならシードを入れ、必要に応じてHTTPステータス行とヘッダーを含めます。
    4. 結果をモックサーバー(MSW、json-server など)やテスト用フィクスチャに貼り付けます。

    よくある質問

    モックだけでテストは足りますか?

    画面の動作確認には足りますが、サーバーとの互換性は保証しません。サーバーの形式が変わってもモックのテストは通るため、リリース前にはコントラクトテストやスキーマ検証を別に置くのが安全です。

    204 を選ぶと本文は空になりますか?

    はい。RFC 9110 では 204(と 304)のレスポンスはヘッダー後の空行で終わるため、どのスタイルを選んでも本文は作りません。HTTPヘッダーを含めるをオンにするとステータス行とヘッダーだけ(本文がないので Content-Type も省略)、オフだと出力は空になります。

    avatar の画像URLはどこを指していますか?

    外部サービス i.pravatar.cc です。画面に表示するとそのサーバーへリクエストが飛ぶので、オフラインや外部通信を禁じたCIではローカル画像に差し替えてください。

    最大何件まで作れますか?

    total は10,000、per_page は1,000までです。ページネーションでは現在ページ分だけが実際に生成されます。

    出典

    基準日:

    プライバシーとデータの扱い

    関連ツール

    生産性