API ライフサイクル全体でモック サーバーを使用する

モック サーバーは、開発プロセス全体で発生するさまざまな予期しない課題に対する有効なソリューションです。複数の API との統合には時間がかかる可能性があり、個人がデバッグに費やす時間は平均 16% ですが、理想的な状態ではわずか 10% です。外部の依存関係やチームの並行作業によっても、遅延やフラストレーションが生じる可能性があります。ただし、モック サーバーを使用することで、開発者はこれらの障害や中断を最小限に抑えることができるため、開発ライフサイクル全体を通じて貴重なツールとなります。

モックサーバーとは正確には何ですか?

明確にするために、モックサーバーは、開発者が API リクエストとレスポンスをシミュレートできるようにする Apigit プラットフォームで利用可能なツールです。リクエストがモック サーバーに送信されると、リクエストの構成と保存されている例が一致し、対応するデータを含むレスポンスが返されます。

モック サーバーは、開発者がコードを記述する必要なく、運用環境で API の応答をシミュレートする方法を提供します。モック サーバーを使用することで、API インフラストラクチャ開発のフィードバック ループが短縮され、イテレーションの高速化と迅速な開発が可能になります。

このブログ投稿では、モック サーバーを使用する利点と、モック サーバーを使用して開発ワークフローを改善する方法について説明します。 Apigit には、モック サーバーを作成するためのいくつかの方法が用意されています。

コラボレーションのためのモック サーバーの使用

ほとんどの場合、開発プロジェクトには、プロジェクトのさまざまな側面に同時に取り組む複数のチームと個人が関与します。これには、小規模なプロジェクトであっても、フロントエンド開発者、バックエンド開発者、QA エンジニア、およびその他の専門家が含まれます。生産性と効率を最大化するために、チームがプロジェクトのさまざまな部分に同時に取り組むのが一般的です。

モック サーバーは、開発プロセス全体で効率を維持するのに役立つ汎用性の高いツールであり、API のプロデューサーとコンシューマーの両方に利益をもたらします。これらは、API 開発ライフサイクルのさまざまな段階で利用できます。たとえば、フロントエンド チームがバックエンドまたはサーバーからのデータを統合したい場合、モック サーバーを使用して、まだ完全に構成されていない、または機能していない API エンドポイントをシミュレートできます。これにより、完全な API 機能がない場合でも、フロントエンド エンジニアリングが正確かつ可能になります。

モック サーバーは、設計段階など、開発プロセスの初期段階で利用できます。 API エンドポイントが開発およびデプロイされるのを待つ代わりに、Apigit を使用すると、開発者は API 仕様からモック サーバーを作成できます。これにより、フロントエンドで使用するサーバー レスポンスをシミュレートできます。これにより、UI 開発者は、モック サーバーにクエリを実行し、期待される応答を処理することで、すぐに作業を開始できます。実際の API が本番環境で使用できるようになると、開発者はモック API 応答の URL を実際の API の URL に (必要な承認と共に) 交換できます。

外部依存関係をモックして効率的にテストする

API と開発プロジェクトは独立したエンティティではなく、バックエンド開発では外部サービスとの統合が必要になることがよくあります。ただし、外部サーバーへの呼び出しは制御できないため、503 Service Unavailable エラーが返されるなど、予測不能で信頼できない結果が生じる可能性があります。前述のとおり、API の問題のデバッグには、開発時間全体の最大 16% が費やされる可能性があります。プロジェクトが複数の外部 API に依存している場合、API へのアクセスで問題が発生し、進行が妨げられる可能性があります。ただし、これらの問題によって開発が完全に停止するわけではありません。

外部 API 呼び出しは、多くの場合、開発ワークフローの重要なコンポーネントですが、開発中に外部サービスに依存することは危険です。このリスクを軽減するために、モック サーバーを使用して、外部サーバーにアクセスし、期待される応答を返すエクスペリエンスをシミュレートできます。これは、外部サーバーまたは API への呼び出しが開発プロセスの重要なコンポーネントである場合に特に役立ちます。

このシナリオでは、モック サーバーは、開発ライフサイクルのローカル テストおよび開発フェーズを支援します。理論的な例を見てみましょう。

注文フローを使用して e コマース アプリケーションを開発しているとします。API は、同期を維持する必要がある配送サービスと結合されています。具体的には、e コマース アプリでアイテムがカートに追加されたら、配送サービスのカートにも追加する必要があります。これにより、配送サービスは、配送する必要があるものを追跡できます。これは、API に対して行われたすべてのリクエストが、配送サービス API へのリクエストもトリガーすることを意味します。

e コマース サイトをテストしているが、Shipping API の問題により生産性が停止している視覚的な例

API 開発の重要な部分の 1 つは、プロジェクトが依存する外部サービスまたは API が機能し、期待される結果を返すようにすることです。ただし、外部サーバーへの呼び出しは常に信頼できるとは限らず、予期しないエラーが発生する可能性があるため、デバッグが必要になります。このような場合、外部サーバーにヒットして期待される応答を返すという経験をシミュレートすることで、モック サーバーが役立ちます。

開発ライフサイクルのローカル テストおよび開発段階では、モック サーバーはワークフロー内の個々の API を分離するのに役立ちます。 e コマース アプリケーションの場合の配送サービス API などの外部 API 用にモック サーバーを構成することにより、API がダウンしていても、API からの期待される結果に基づいて作業を続行できます。これにより、テスト プロセスがより効率的になり、API の障害が原因でプロジェクトが停止する可能性が減少します。

e コマース アプリケーションの注文フローをテストする場合、API は配送サービスと同期している必要があります。ただし、出荷 API がエラーを返すかダウンしている場合、開発とテストの遅延が発生する可能性があります。このような依存関係を回避するために、モック サーバーを使用して、外部サービスからの予想される応答をシミュレートできます。 Apigit を使用すると、開発者は各 API を個別にテストし、特定の問題を特定できます。出荷 API 用のモック サーバーを構成することにより、開発者は、出荷 API がダウンしても、期待される結果に基づいて作業を続行できます。次の図は、出荷 API をモック サーバーに置き換えた同じワークフローを示しています。これにより、内部 API が期待どおりに機能している限り、テストを中断することなく続行できます。

モック サーバーを使用して Shipping API をシミュレートしながら e コマース サイトをテストする視覚的な例

私にデータを話してください

データ共有は、使用されるプロトコルや HTTP 動詞に関係なく、API の中心にあります。ただし、このデータには、テスト目的で使用したくない機密性の高い個人情報が含まれている可能性があります。一方、「John Doe」のようなプレースホルダー データを使用すると、単調で非現実的なものになる可能性があります。そこで役立つのがモックサーバーです。

モック サーバーは、プライベート データを保護する必要がある場合や、実稼働のようなワークフローをシミュレートする場合など、日常のテストとトリッキーなユース ケースの両方を管理するのに役立ちます。

Apigit を使用すると、密結合された一連のリクエストと対応するレスポンスの例からモック サーバーを生成することで、モック サーバー用の動的データを作成できます。デフォルトの保存された例に頼る代わりに、ニーズに合わせて応答をカスタマイズできます。

これを実現する 1 つの方法は、応答の例を編集して動的変数を含めることです。このアプローチにより、モック サーバーは組み込みライブラリを利用して、実際のデータを模倣したダミー データを提供できます。

インターネットは予測不可能な場所です — モックで開発ライフサイクルに秩序をもたらしましょう

開発者は、制御可能なものを制御することに集中するスポーツと同様の考え方を採用できます。開発中、外部 API の安定性は常に制御できるとは限りませんが、モック サーバーを使用して何が起こるかをシミュレートし、予期しない問題を減らすことができます。モック サーバーを使用することで、開発者は作業を効果的に行うために必要な安定性を生み出すことができます。したがって、モックサーバーは、開発者が混乱や予期しない問題を起こさずに目標を達成するために必要な安定性となります。