API をモックしてテストする
学習の目的
この単元を完了すると、次のことができるようになります。
- API モッキングによってチームがバックエンドを構築する前にどのように動作をプレビューできるかを説明する。
- API コンソールが要求と応答のシミュレーションとテストにどのように役立つかを特定する。
- モックされた API によって関係者による早期フィードバックが可能になるしくみを説明する。
API モッキングとテストが重要な理由を学ぶ
API が作成される前に、チームには意図したとおりに動作することを確認する方法が必要です。モッキングでは、バックエンドコードを記述する前に、設計プロセスの早い段階で API の動作をシミュレーションします。
API のモッキングは、開発者と関係者が早期に設計を検証するのに役立ちます。チームは、開発が開始する前に、API のエンドポイント、応答、インタラクションがビジネスニーズに沿ったものであることを確認できます。こうすることで、再作業が減り、フィードバックが加速化し、修正コストがかさむ前にチームが問題を検出できるようになります。
この単元では、モッキングを介して実装前に API の動作をシミュレーションする方法と、それが早期に関係者からフィードバックを収集するのにどう役立つかを見ていきます。また、API コンソールを使用して要求の送信と応答の検証を行う方法も学びます。
サンプルデータを使用して API をテストする
API は、実装前に設計して検証する必要がありますが、 バックエンドが構築される前に API をテストするにはどうすればよいのでしょうか? ここで登場するのがモッキングです。
API モッキングを使用すれば、開発者は設計プロセスの早い段階で API の動作をシミュレーションできます。これにより、チームはエンドポイントのテスト、応答の検証、関係者との API の共有すべてを、バックエンドコードを 1 行も記述することなく行えます。
モッキングのしくみ
Anypoint Code Builder や API Console のようなツールには、API 定義から一時的なエンドポイントを生成するモッキングサービスが組み込まれています。このモックされた API により、次のことが可能になります。
- 異なる要求に API がどのように反応するかをプレビューする。
- 要求形式と応答形式が OpenAPI 仕様 (OAS) 定義に従っていることを検証する。
- シミュレーションされた API バージョンを社内チームや外部パートナーと共有する。
モッキングを使用すれば、開発に時間と労力が向けられる前に、設計の問題を早期に検出し、API がビジネスニーズに沿っているかを確認することが容易になります。
Mule United Airport で API をモックする
Mule United Airport のシナリオに戻りましょう。開発者はフライト予約 API のバックエンドロジックを記述し、次のことを検証します。
-
/flightsエンドポイントがdeparture、dateのようなパラメーターを受け入れる。
- 応答に正確なフライトデータが含まれている。
- 構造が関係者の期待に応えている。
モッキングにより、チームは設計の評価と改善のすべてを API の実装前に行えます。
API コンソールで API をテストする
API をモックしたら、API コンソールを使用してテストします。このインタラクティブツールを使用すると、要求の送信とリアルタイムの応答の表示を行えます。
API コンソールの実行内容
API コンソールにより、次のことが可能になります。
- 要求を API エンドポイント (モック URL を含む) に送信する。
- API によって想定されるデータが返されることを確認する。
- パラメーターの欠落や不正な要求形式などのエラーを確認する。
モッキングにより、チームは開発前に API をテストできます。API コンソールでは、API が実装されたらライブ API もテストできます。
API テストが重要な理由
API テストにより、インテグレーションの失敗、不正確な応答、コストのかかる再作業が減少します。API コンソールは、次のことを検証するのに役立ちます。
- 正しい HTTP メソッドが使用されている (
GET、POST、PUT、DELETE)
- 必要なパラメーター (フライト ID や検索条件など) が含まれている
- 想定される形式に従って応答が返され、正しいデータが含まれている
API コンソールでのトラブルシューティングへのサポート
API 要求または API 応答が想定される内容ではない場合、コンソールで詳細なエラーメッセージを表示できます。よくある問題には次のものがあります。
-
400 Bad Request: 要求が無効である、または必要なパラメーターが欠落している。
-
401 Unauthorized: 認証が必要だが欠落している、または正しくない。
-
404 Not Found: 要求されたリソースが存在しない。
チームは、コーディングが開始される前に、API コンソールで要求をシミュレーションして確認し、設計の問題を特定して解決することができます。
早期フィードバックのためにモック API を共有する
モックされた API は開発者のみに役立つわけではありません。ビジネス関係者、テスター、フロントエンドチームにとっても価値があります。実装前に、チームは早い段階で API をチェックして使用し、ビジネスニーズを満たしているかを確認することができます。
Anypoint Code Builder、Anypoint Exchange などのツールでは、バックエンドの設定を必要とせずに、モックされた API を関係者と共有できます。これには、実際の API チームがフィードバックを収集し、再作業を減らし、認識を一致させるプロセスが反映されます。
共有が重要な理由
- 関係者が早い段階で API 設計を確認して改善点を提案できます。
- フロントエンドチームがバックエンドチームと並行して開発を開始できます。
- QA チームが実装前に構造と想定される動作を検証できます。
- 外部パートナーが内部システムにアクセスする必要なく API を確認できます。
共有のしくみ
モックされた API が Anypoint Exchange のようなプラットフォームを介してパブリッシュされると、公開ポータルが自動的に作成されます。通常、このポータルには API コンソールが含まれます。ここで、ユーザーは仕様で定義されたデータ例を使用してエンドポイントをテストできます。1 つの公開リンクを関係者と共有できるため、フィードバックを簡単に提供できます。
MUA の API チームがモックされた API のテストと共有を行う方法を学ぶ
MUA では、API チームが複数のグループで使用できるフライト予約 API のモックされたバージョンを作成します。
-
製品マネージャーは、必要な予約ワークフローがサポートされているかどうかを確認します。
-
フロントエンド開発者は、バックエンドコーディングの開始前にインテグレーションの準備を行います。
-
QA テスターは、想定される応答が API によって生成されることを検証します。
テスト可能な API を設計する
開発者は、OAS の主要なリソースとメソッドを定義します。一般的な例には次のようなものが含まれます。
/flights リソースと次のメソッド:
-
departure、destination、dateのようなクエリパラメーターを受け入れるGETメソッド - フライト予約を処理するための
POSTメソッド
/flights/{id} リソースと次のメソッド:
- 特定のフライトを取得するための
GETメソッド
各メソッドは、仕様にデータ例を含みます。このデータ例によりモック応答が強化され、関係者はバックエンドなしで API の動作をプレビューできます。
ヒント
モッキングサービスによって、サンプル応答が自動的に作成されることはありません。OAS ファイルに定義された例が使用されます。
モック応答データを追加する
Anypoint Code Builder、Anypoint Exchange にあるようなモッキングサービスでは、仕様に定義された応答例を使用して動作をシミュレーションします。
以下は、YAML で定義される可能性のある GET/flights の応答の簡単な例です。
responses:
'200':
description: Successful response
content:
application/json:
example:
- flightNumber: MU123
airline: Mule Air
departure: 2025-06-01T08:00:00Z
arrival: 2025-06-01T11:00:00Z
origin: JFK
destination: LAXこの例により、実際に使えるバックエンドがなくても、API がテストされたときにモッキングサービスで現実的なペイロードを返すことができます。
Anypoint Exchange にパブリッシュする
API の準備が整ったら、チームはその設計を Anypoint Exchange にパブリッシュします。これにより、一般に公開される API ポータルが作成され、API コンソールを介する組み込みのテストが使用できるようになります。
チームが Anypoint Exchange にパブリッシュするときには、通常、次のことを行います。
- アセット名 (例: American Flights API) とバージョンを設定する。
- ライフサイクルの状態 (例: 安定) を割り当てる。
- アセットを公開にするか非公開にするかを選択する。
- Anypoint Exchange にドキュメントとモック対応 API コンソールを含むポータルの自動生成を許可する。
このプロセスにより、API の確認とテストが行いやすくなります。
API を確認して検証する
モック対応ポータルがライブになっていると、関係者はエンドユーザーが行うのとまったく同じように API を操作できます。API コンソールを使用して、次のことを行えます。
- テスト要求をエンドポイントに送信する (例:
GET/flights)
- クエリパラメーター値を提供する (例:
departure=JFKまたはdate=2025-06-01)
- データ例から返されたシミュレーション済みの JSON 応答を確認する
これにより、製品マネージャー、フロントエンド開発者、QA テスター、パートナーは、コードが記述されるよりずっと早い段階で、想定どおりに API が機能することを確認できます。
公開アクセスを有効にする
多くの場合、チームはポータルへの公開アクセスを有効にする必要があります。ブラウザーのプライベートウィンドウかシークレットウィンドウでポータルを開き、API コンソールが機能することを確認します。
正しく設定されている場合、モック API は次のように機能します。
- 想定されるデータ例で応答する。
- 特別な認証も内部アクセスも必要としない。
- リンクを知っている人なら誰でもフィードバックを行えるようにする。
先に進む前に API チームが確認する事項
モックされた API の共有とテストが終わったら、大半のチームは次のことを確認します。
- 適切なリソース、メソッド、パラメーターが設計に含まれている。
- API コンソールでテストされたときに、応答例が正しく返されている。
- モックされた API が Anypoint Exchange の公開ポータルまたは共有可能なポータルからアクセスできる (有効化されている場合)。
- 主要な関係者が API を確認し、早期フィードバックを行っている。
これで、API がビジネスニーズに沿ったものとなり、開発に進む準備が整いました。
まとめ
静的な定義からテスト可能かつ共有可能な設計へと続く実際の API の道筋をすべてバックエンドなしでたどりました。次の単元では、Anypoint Exchange ポータルをカスタマイズして API の本番での使用とパートナーによる採用に向けた準備を行う方法を学びます。