Apidogを使い回す
本文では、Apidogを利用し始めようとするユーザーに対して、コア機能を紹介します。 30分間ほどの所要時間が必要です。
Apidogが選ばれた理由
開発チームがAPIの設計、管理、テストのために、Postman、Swagger、Stoplight、Jmeterなどのさまざまなツールを使用していることが多いことを観察しました。ただし、これらのツール間でのデータ同期とコラボレーションがないので、効率が大幅に下がる可能性があります。
開発チーム全体が単一のAPIツール内ですべての作業をやり遂げるのは、より良い解決策だろうと思っています。APIドキュメントが定義されている限り、バックエンド開発者はAPIを簡単に実装して自己テストを行い、フロントエンド開発者はAPIを簡単に呼び出してMockデータを使用し、テストエンジニアはAPIを直接テストしてテストケースを簡単に生成できたら、チーム協同作業の効率が大幅に向上できるのでしょう。
これこそ、私たちはApidogを始めたきっかけです。Apidogは、チームの協同作業のために設計されていて、APIの設計、開発、テスト、管理、ドキュメント生成やMockなどのことが実現され、今までにない包括的なAPIツールです。
Apidogとは
Apidogは、API開発のためのオールインワンツールキットです。チーム全体が協力して、APIをより効率的かつ便利に作成するために開発されているものです。チームの各メンバーは、それを使って自分の問題解決を図ることができます。
Apidogは、APIの設計と開発をユーザーインターフェイスより優先する開発アプローチ(いわゆるAPIファーストアプローチ)を採用しています。このアプローチには、次のようないくつかのメリットがあります。
- Apidogを使用すると、チームの各メンバーは同時に作業を進んでサービス間で合意を達成することで、複数のAPIで同時に作業し、開発速度を大幅に向上させることができます。
- 自動化は、APIの定義ファイルのインポートツールを通して実現され、APIの開発と実行に必要な時間を短縮できます。
- 直感的なデザインと十分に文書化されたAPIドキュメントにより、開発者の優れたエクスペリエンスが保証されます。また、開発者が簡単にコードを使用・再利用し、新しい開発者をオンボードし、学習コストを減らすこともできます。
- コードが書かれる前にも、ほとんどの問題を解決することができるので、APIをアプリケーションに統合する際に問題を発生することを防ぐこともできます。
API設計者:APIの作成
API設計者はApidogを使用して、APIを視覚的に作成するか、OpenAPIの仕様からインポートします。
OpenAPIの仕様からインポート
APIがOpenAPIまたはその他の形式で指定されている場合は、Apidogにインポートすると、簡単にデバッグ、テスト、またはMockすることができます。
- Apidogのプロジェクトで
インポート
をクリックします。
URLのインポート
を選択して、次のURLを貼り付けて、提出
をクリックします。
https://petstore.swagger.io/v2/swagger.json
JSONとYAMLファイルからのインポートも可能ですが、Apidog、HARなど、他のAPI仕様の形式もサポートされています。
確認
をクリックしてインポートします。
- ここでApidogを使用してAPIを実行するか、テストすることができます。
データのインポートの詳細を ここで見る。
新しいAPIを作成
API設計者は非常に直感的なインターフェース内でAPIを作成できます。
- 新しいタブで
新しいAPI
をクリックしてエンドポイントを作成します。
- 次に、IDでユーザー情報を照会するためのAPIを指定します。そのため、次のフィールドをAPIに入力できます。
- APIパス:
/users/{id}
- 名前:
IDでユーザー情報を取得
- APIパス:
- このAPIには、QueryパラメータとBodyパラメータがありません。ここで「Id」がPathパラメータとして認識されると、「Request」の部分が完成しました。
Response
部分に移動して、「OK (200)」でルートノードのフィールドタイプを「参照モデル → Schemas → ApiResponse」に変更します。
- ここでAPIは、次のような一般のJSON構造を生成しました。全てのAPIも異なる「data」フィールドがあるため、ルートノードに「data」と名付けられた子ノードを追加します。
- 「data」ノードのフィールドタイプを「参照モデル → Schemas → User」に変更します。
- ここでResponseをうまく設定できました。「data」構造内のデータを編集する場合は、スキーマ参照を解除するか、編集したいフィールドの参照を解除する必要があります。
データSchemaの詳細を ここで見る。
Responseの例
の部分に移動して、例を追加
をクリックします。
- 例の名称を「Success」に設定します。ここで
自動生成
をクリックして、戻りデータがResponse構造に基づいて生成されます。OK
をクリックして例を追加します。
保存
をクリックして、APIの作成が完了しました。ここでうまく設計されたAPIが手に入れましたよ。
バックエンド開発者:APIの開発とデバッグ
異なるチームは異なる開発アプローチを採用しています。APIファーストを採用しているチームもありますし、コードファーストを採用しているのもあります。ただし、チームがどの方法を採用していても、バックエンド開発者はApidogを使用してAPIの開発とデバッグを簡単に実現できます。
コードの生成
- APIが指定された場合、 スタブサーバーとクライアントSDKが簡単に生成されます。APIページで
コード生成
ボタンからすべてのコードを生成
をクリックするだけです。
- OpenAPI Generatorエンジンを利用して、スタブサーバーとクライアントSDKを数十個の言語で生成できます。
コード生成の詳細を ここで見る。
APIを実行
APIの開発が完了すると、多くの場合ではバックエンドの開発者は、APIが異なるパラメータで正確な結果を返すかをデバッグする必要があります。Apidogを使用すると、各APIをデバッグし、正常に実行できることを簡単に確認できます。
- 先に作成したAPIのページで、
実行
ボタンをクリックして実行
タブに移動します。
- 「id」パラメータのパラメータ値で「1」を入力します。ここで送信待ちのrequest URLの中の {id} は、「1」に置き換えられます。
- 画面の右上角の
環境の管理
ボタンをクリックします。
- 「テスト環境」に切り替えて、次のURLを「Default Sever」サービスに貼り付けます。その後、環境を保存します。
https://mock.apidog.com/m1/352945-0-default
環境管理の詳細を ここで見る。
- そして、「Testing Env」を選択すると、先に設定したBase URLは、送信待ちのすべてのrequestsの先頭に追加されます。
送信
をクリックしてRequestを送信します。APIのResponseは下の部分で表示されます。
デバッグ
APIの開発が環境を設定した後、 バックエンド開発者は、期待のデータを返しているか、APIが正しいロジックを実装しているかをテストする必要があります。
- pathパラメータの値を「2」に設定して、 Requestを
送信
します。
- 「$.data.id should be integer」という警告が表示されます。なぜかというと、$.data.idはintegerである必要がありますが、実際に返された$.data.idはStringになっているからです。
- Apidogは、APIの定義と実際のResponseが一貫しているかどうかを自動的に検証します。正しくないデータタイプ、定義されていない列挙値、必須フィールドの欠落などの問題は自動的に検出されます。バックエンド開発者は、戻りデータの問題を簡単に検出できます。
APICaseを保存
ボタンをクリックしてRequestを保存します。 当該RequestはAPIの子ディレクトリに保存され、テストモジュールに参照されることができます。
変数の利用
Apidogでは、変数がRequest間で再利用可能な値を格納するために利用されています。
環境変数は環境に繋がっています。つまり、特定の環境が選択された場合にのみアクセス可能です。一方、グローバル変数は、すべての環境でアクセスできます。
Apidogの「環境の管理」セクションで環境変数を定義し、{{variableName}}のように二重波括弧を使用して、Requestで環境変数を参照できます。
例:
- pathパラメータ「id」の値に{{Userid}}を入力します。
- 環境管理をクリックします。
Userid
と名付けられた変数を新しく追加し、ローカル値
に「1」を記入して、変数を保存します。
- Requestを送信します。
Response
-実際のRequest
の順にrequest URLを確認できます。ここで {{Userid}} はローカル値
に置き換えられたことを確認できます。
変数の詳細を ここを見る。
前処理
Apidogでは、前処理はRequestを送信する前に実行される操作です。これにより、Requestが送信される前にRequestと環境変数を操作できます。
前処理の利用シーン:
- Requestで利用されている変数の設定と編集
- データ検証、またはデータ変換の実行
- Headerの追加と編集
- ログ情報とデータのデバッグ
- 他のReuqestを行い、そのResponseデータを変数への保存
- Request URLの編集
これらの操作はJavaScriptに書き込まれ、Postman SDKでRequest、Responseオブジェクト、環境変数、及びグローバル変数にアクセスできます。Scriptが追加されると、Requestが送信されるたびに実行されます。
前処理のRequestパラメータ値を変更する例:
前処理
タブをクリックし、前処理を追加
ボタンをクリックしてカスタムScript
を追加します。
- 次のScriptを
カスタムScript
エリアに貼り付けます。
let Userid = parseInt(pm.environment.get("Userid"));
Userid = Userid + 1;
console.log(Userid);
pm.environment.set("Userid", Userid);
カスタムScript
を変数置換&親を継承
にドラッグして、Requestを送信します。
- 送信した後、 {{Userid}}の値が2になったことを確認できます。そして、Requestを複数回送信する場合、送信する度に、 {{Userid}} の値に1をプラスするようになります。
- 共通Script、データベース操作及び待機時間は、前処理に追加可能な項目です。
Scriptの詳細を ここで見る。
フロントエンド開発者: APIのMock
APIのMockは、テストと開発の目的で使用されるAPIのシミュレートされたバージョンです。これにより、開発者はライブAPIに依存せずにアプリケーションやサービスをテストでき、送信のRequestに特定のResponseを返すように構成できます。
指定されたAPIに基づいて、Apidogは設定なしでMockデータを自動的に生成できます。それはフロントエンド開発者にとって非常に便利な機能です。
API
タブでローカルMock
を選択します.そして、 Click theURL/パラメータ
をクリックして、「OK(200)」をコピーします。
ブラウザでURLを貼り付けます。そして、生成されたJSONが見えます。そのデータはダイナミックで、ページをリフレッシュする度にデータが変わります。
特に、生成されたデータには、「email」や「lastName」のような項目があります。ご覧のように、これらの値は非常に合理的で現実みたいものになります。この機能は、Apidogの
スマートMock
と言います。
変更
タブのResponse
部分で 「ApiResponse」Schemaの参照を解除
します。
- ノード内の各
Mock
値を入力して、APIを保存
します。- code
200
- type
JSON
- message
Success
- code
- ブラウザでページを再読み込みすると、JSONデータが更新され、「code」、「type」、および「message」フィールドが設定に従って生成されます。現在、フロントエンド開発者は単にURLを使用して、開発中のクライアントでデータを取得できるようになります。
- Mock設定は、
Faker.js
をもサポートしています。任意のFaker.js文法を選択してダイナミックのMockデータを生成できます。
- MockのResponseを修正する必要がある場合、
設定
-機能設定
-Mock設定
-デフォルトMockタイプ
の順にクリックし、Response例を優先
に切り替えます。ApidogのMockエンジンは、 API Responseの例をMockのResponseとして使用します。
ApidogのMock機能は、クラウドMockもサポートし、さまざまなRequestパラメータに対して異なるMock Responseを返したり、Scriptを使用してMockのResponseを書き換えたり、賢いMockマッチングルールをカスタマイズしたりすることができます。 Mockの詳細を ここでを見る。
QAエンジニア:APIのテスト
Apidogの自動テストモジュールにより、QAエンジニアはAPIの定義またはAPIケースを参照して、テストのシナリオを直接に生成できます。データ駆動型テストをサポートし、ダイナミックのテストデータを簡単に生成できます。また、アサーションと変数抽出機能により、テストケースの作成を非常に簡単にしました。ApidogはCI/CDもサポートしています。
アサーション
Apidogでは、後処理でサーションを追加することができます。また、Postman SDKを使用してカスタムスScriptでアサーションステートメントを追加することもサポートしています。
Get user by id
-Success
という保存ケースに移動して、後処理
タブで後処理を追加
-アサーション
の順にクリックします。
- アサーションで次のパラメータを設定します:
- Response JSON
- $.code
- Assertion
- 等しくない: 200
- Response JSON
JsonPathの詳細を ここで見る。
Reuqestを
送信
すると、アサーション結果
を確認できます。Apidogは、Response JSONから$.codeの値を取得して、アサーションと比較します。マッチングする場合、アサーション結果は合格になります。
後処理
では、変数抽出
,カスタムScript
,共通Script
,データベース操作
と待機時間
も追加されることができます。MySQL、SQL Server、Oracle、PostgreSQL、およびClickHouseデータベースは、Apidogでサポートされています。SQLステートメントを実行でき、SELECT結果を変数に抽出できます。INSERT、DELETE、UPDATEなどの他のSQLも実行できます。
データベース操作の詳細を ここで見る。
シナリオテスト
アサーションを書いた後、複数のAPIケースを同じ単一のテストケースにインポートし、1クリックで実行してテストレポートを生成します。
自動テスト
モジュールにアクセスして、新規テストケース
を作成します。
- 当該ケースの設定を終了してそれにアクセスします。
ステップを追加
をクリックして、APIテストケースからインポートする
を選択します。
- テストのステップとして、保存したAPICaseを選択して、「確認」をクリックしてインポートします。
- テストケースを行うには、
実行
ボタンをクリックします。そして、詳細なテストレポートが作成され、各Requestの詳細を確認することができます。
- 失敗した項目で
詳細
をクリックし、Responseとアサーションを比較して、うまく行かなかった原因をチェックできます。
テストケースの詳細を ここで見る。
データ駆動型テスト
APIケースで変数が使用される場合、データテーブルか「動的値」機能を使用して変数の値を自動的に生成するように設定できます。
テストデータ
をオンにして、テストデータを管理する
をクリックします。
- 変数とデータベースを追加し、変数の値も設定します。ここでCSVかJSONからインポートすることもサポートされます。
保存
をクリックして、テストデータの設定を保存します。
- ここテストデータを利用するかを選択して
実行
します。変数の値は、テストケースの反復で使用されます。
テストデータの詳細を ここで見る。
CI / CD
Apidogはコマンドラインでの実行をサポートしています。Apidog CLIをインストールした後、apidog run
コマンドを使用してコマンドラインのテストレポートを取得できます。このコマンドは、Jenkinsでも利用して、CI/CDを実装できます。
- テストケースで「CI/CD」をクリックします。
- テストのパラメータを設定して保存すると、コマンドラインが生成されます。ここで
さらに詳しく
をクリックしてApidog CLIをインストールします。
CI / CDの詳細を ここで見る。
APIの設計者 & APIユーザー: APIドキュメント
APIの設計、開発、デバッグ、テストが終了すると、APIは、他のユーザーが利用できるプロダクトになります。Apidogは綺麗なAPIドキュメントを生成できるため、開発チームはAPIを公開する時に役立ちます。
共有
モジュールにアクセスし、+新しい共有
から共有項目を作成します。
- APIドキュメント実行環境を選択すると、APIドキュメントの利用者は、ここで設定された環境を使用してAPIを実行できます。
- 「開く」をクリックして共有対象となるドキュメントをブラウザで開きます。
- APIドキュメントが生成され、インターネット上で共有できます。また、共有したWebサイトで「送信」することもできます。
コードのサンプル
機能は、APIのRequestコードを数十個のプログラミング言語で生成できます。そして、APIリーダーが生成されたコードで直接にAPIを呼び出すことが可能になります。
Responses
のコード生成
機能は、Responseデータの構造に従ってコードを生成できます。数十個のプログラミング言語がサポートされ、API利用者は、生成されたコードを直接に実装の段階で使用できます。
- ドキュメント機能では、
カスタムドメイン
、上部のナビゲーション
、カタログのスタイル
,コンテンツのフッター
など、他にも多くのカスタム機能はサポートされています。
ベストプラクティス
1.Apidogでは、API設計者(またはバックエンド開発者)がAPIの仕様を定義します。
2.開発チームは協力して、ドキュメントをレビュー&改善し、APIユースケースの一貫性を確保します。
3.Apidogを使用すると、フロントエンド開発者は自動的に生成されたMockデータで開発を開始でき、手動でMockルールを作成する必要はありません。
4.バックエンド開発者は、開発中にAPIユースケースを使用してデバッグできます。デバッグ中にすべてのAPIユースケースが合格した場合、開発完了。また、開発中にAPIの変更がある場合、APIドキュメントもデバッグ中に自動的に更新され、最小限の手間で適時にAPIメンテナンスを行えます。
5.デバッグ後、バックエンド開発者はAPIユースケースとして機能を簡単に保存できます。
6.QAエンジニアは、APIユースケースを使用してAPIを直接にテストできます。
7.すべてのAPIが開発されると、QAエンジニア(またはバックエンド開発者)は、テストケースとテストコレクション機能を使用して、全面的に複数のAPIインテグレーションテストを実施できます。
8.フロントエンドとバックエンド開発の共同デバッグは、両方のチームが同じなAPIの仕様に準拠しているため、フロントエンド開発者がMockデータから実際のデータに切り替える時にも、通常問題が発生しません。
9.API開発が完了すると、Apidogは綺麗なAPIドキュメントを生成し、開発チームがAPIを外部チームに簡単に公開できます。
上記は、Apidogのコア機能と操作ガイドの概要です。Apidogには、開発チームがAPIを効率的に開発してデバッグするのに役立つ機能がたくさん備えていますので、今すぐApodogの使用を開始して探索し始めましょう。