この記事では、Apidogの主要な概念について説明する。他の類似製品（Postmanなど）とは異なる概念が多いため、これらの定義と違いを理解することで、Apidogのワークフローをより深く理解できる。設計優先 & リクエスト優先#
ApidogのAPI管理モジュールには、インターフェースの左下隅で切り替え可能な2つのモードがあります：「設計優先」と「リクエスト優先」です。どちらのモードも似たような機能を提供しますが、インターフェースが異なり、異なるチームのワークフローに対応しています。設計優先は、Apidogが推奨するモードで、設計優先アプローチを採用するチームに適しています。このモードでは、チームはまずAPIの仕様を決定し、その後、API仕様に基づいて開発とテストを進めます。一方、リクエスト優先は、最初にAPI仕様を定義しないチームに最適です。これらのチームは通常、バックエンド開発に集中し、コードを完成させた後にAPI仕様を作成し、テストやクライアント側の作業を開始します。他の人が開発したAPIを呼び出す必要があるが、ドキュメントがない場合も、リクエスト優先モードを使用するべきです。API#
Apidogは API ファーストの製品で、すべては API の定義から始まる。API の中で最も重要な要素が API だ。Apidogのメイン画面では、API がディレクトリ形式でグループ化された基本要素として表示される。各 API に対して、「定義の編集」、プレビュー、API 仕様に基づくリクエストの送信、そしてリクエストを API ケースとして保存することができる。この構造は Postman とは大きく異なり、OAS（API 仕様）をベースに拡張した形に近い。つまり、デバッグやリクエストの保存が直接できる API 仕様という考え方だ。Postmanでは、基本要素はリクエストで、リクエストは API 仕様とは本質的に切り離されている。そのため、API 仕様が変更されると、すべてのリクエストとスクリプトを書き直す必要がある。一方、Apidogでは、すべての API ケース（Postmanでいうリクエスト）は API 仕様に基づいている。API 仕様が変更されると、API ケースも自然に変更され、それに基づくすべてのテストシナリオや CI/CD も自動または手動で更新できる。これは開発チームが API を管理・更新する上で非常に便利な仕組みだ。Request#
テストシナリオ#
複数のリクエストをまとめて送信する必要がある場合（Postman Collectionの実行に相当）、テストシナリオを使用する。Apidogの環境 は、Postmanの環境と同様に、多くの変数を含んでいる。環境を切り替えることで、同じ環境変数の異なる値を使用できる。ただし、Apidogの環境には、サービスというもう一つの重要な概念がある。各サービスは接頭辞URLに対応している。OASで定義された API はすべて / で始まるため、異なるサービスに送信できる。Apidogでは、リクエストの先頭に {{Base_url}} を書いて、サービスを変数の形で保存する必要はない。対応する環境に切り替えるだけで、すべてのリクエストがその環境の対応するサービスに直接送信される。プロジェクト#
API、リクエスト、Schema、環境、テストシナリオなどの集まりがプロジェクトを形成する。Apidogでは、プロジェクトが共同作業の基本単位となる。 Modified at 2025-03-28 10:12:02
