ApidogのベースURLを使用すると、エンドポイントアドレスの繰り返し部分を抽出して一元的に管理できます。
例えば、エンドポイントがhttps://api.example.com/v1/usersの場合、https://api.example.com/v1をベースURLとして設定できます。そうすれば、エンドポイントの定義では/usersと記述するだけで済みます。
リクエストを送信する際、ApidogはベースURLとエンドポイントパスを自動的に結合して完全なリクエストアドレスを形成します。これにより、サーバーアドレスが変更された場合でも、ベースURLを更新するだけで済み、個々のエンドポイントを修正する必要がなくなります。
ベースURLの設定手順
Apidogプロジェクトを開き、右上の「環境管理」を見つけてください。Apidogはデフォルトで、開発、テスト、本番など、いくつかの一般的な環境を作成します。これらのプリセットを使用するか、必要に応じて新しい環境を作成できます。
環境を選択すると、「ベースURL」入力ボックスが表示されます。プロトコル（http://またはhttps://）から始まるベースアドレスを入力してください。例えば、https://test.server.comや、バージョン番号を含むhttps://api.example.com/v1などです。
**末尾のスラッシュを追加しない**ようにしてください。OpenAPI仕様によれば、ベースURLは/で終わる**べきではなく**、エンドポイントパスは/で始まる**べきです**。
Apidogでの互換性の向上と、より完全な機能体験のために、OpenAPI仕様に従うことをお勧めします。
エンドポイントでのベースURLの使用
新しいエンドポイントを作成する際、URLフィールドにはエンドポイントパスを入力するだけで済みます。例えば、ユーザーリストのエンドポイントをテストするには、/usersと入力するだけで、Apidogが自動的に完全なリクエストURLhttps://api.example.com/v1/usersに結合します。
エンドポイントパスに/users/123/profileのように複数の階層が含まれる場合でも、同じ方法で対応できます。ApidogはベースURLとパスを自動的に結合して完全なリクエストURLを形成します。
注：エンドポイントURLに完全なアドレス（http://またはhttps://で始まるもの）を入力した場合、ベースURLは**使用されません**。Apidogは、指定された完全なアドレスを優先します。
複数の環境でのベースURLの管理
ほとんどのプロジェクトには、開発、テスト、本番など、それぞれ異なるサーバーアドレスを持つ複数の環境があります。各環境に異なるベースURLを設定できます。
例：
右上の隅から環境を切り替えると、すべてのエンドポイントは選択された環境のサーバーアドレスを自動的に使用します。
エンドポイントのアドレスバーで直接環境を選択することもできます。そこには各環境のデフォルトのベースURLが表示されます。「環境管理」パネルで環境を切り替えるのと同様に機能します。
注： 環境に複数のベースURLがある場合、アドレスバーにはデフォルトのベースURLのみが表示されます。特定のエンドポイントでデフォルト以外のベースURLを使用するには、エンドポイント内で手動で設定するか、**モジュール**を介して管理する必要があります。
このマルチベースURL設定は、異なるエンドポイントが異なるサービスアドレスを使用する必要があるマイクロサービスアーキテクチャで一般的です。
マイクロサービスでのベースURLの管理
プロジェクトがマイクロサービスアーキテクチャを使用しており、すべてのエンドポイントが同じベースURLを共有しない場合、ApidogでベースURLを管理する方法は2つあります。
モジュール内でベースURLを手動で指定する
異なるサービスのエンドポイントを単一のモジュールにグループ化し、特定のフォルダーまたは個々のエンドポイントに異なるベースURLを割り当てることができます。この設定は柔軟で、一元管理を好むチームに適しています。
例えば、異なるサービスに対して複数のベースURLを持つモジュールを設定できます。
次に、**「ユーザーサービス」**のベースURLをuserフォルダーに、**「注文サービス」**のベースURLをorderフォルダーに割り当てます。各フォルダー内のすべてのエンドポイントは、対応するベースURLを自動的に使用します。
フォルダーごとに設定したくない場合は、個々のエンドポイントにベースURLを設定することもできます。エンドポイントの「編集」ページを開き、ドロップダウンメニューから目的のベースURLを選択するだけです。
ただし、サービスの数が増えるにつれて、この方法でのベースURLの管理は面倒になり、維持が困難になる可能性があります。小規模なプロジェクトではうまく機能するかもしれませんが、大規模なプロジェクトではすぐに管理が難しくなります。
より良いスケーラビリティと明確さのために、より構造化されたアプローチをお勧めします：
**各サービスを独自のモジュールに分離し、モジュールレベルでベースURLを設定します**。これにより、プロジェクトが整理され、はるかに維持しやすくなります。
モジュールによるサービスの整理（推奨）
各サービスに対して個別のモジュールを作成し、すべての環境で「環境管理」の下にそのベースURLを設定します。このアプローチはより整理されており、チームコラボレーションと長期的なメンテナンスに理想的です。
例えば、**ユーザーサービス**、**注文サービス**、**製品サービス**に対して個別のモジュールを作成し、それぞれを独自のSwaggerまたはOpenAPI仕様ファイルにリンクさせることができます。
モジュールの設定が完了したら、「**環境管理**」ページに移動すると、ベースURLの設定がモジュールごとにきれいにグループ化されて表示されます。
各環境は同じモジュール構造を共有しますが、各モジュールのベースURLは環境によって異なる場合があります。これにより、各環境のすべてのモジュールに特定のベースURLを割り当てることができます。例えば：
この設定により、モジュール内に新しいエンドポイントを作成するたびに、現在の環境の正しいベースURLが自動的に使用され、手動で選択する必要がなくなります。例えば：
- 「ユーザーサービスモジュール＆本番環境」では、デフォルトのベースURLは
https://user.example.comです。 - 「注文サービスモジュール＆テスト環境」では、
http://192.168.1.12:8080です。
「**モジュール＋環境**」の組み合わせを、リクエストURLを正確に決定する座標系と考えてください。モジュールと環境が適切に整理されていれば、Apidogは各リクエストに対して正しいベースURLを自動的に選択します。
「このエンドポイントはどのアドレスを使用しているのだろう？」と疑問に思う必要はありません。適切なモジュールと環境を選択するだけで、残りはApidogが処理します。
ベースURL使用の実践的なヒント
- APIにバージョン番号が含まれる場合は、ベースURLに直接追加します。例：
https://api.example.com/v2。これにより、APIバージョンをアップグレードする際に、すべてのエンドポイントではなくベースURLのみを更新すればよくなります。 - サードパーティサービスを呼び出すなどの特殊なケースでは、エンドポイントに完全なURLを直接入力できます。これにより、デフォルトのベースURLが自動的に上書きされます。
結論
ベースURLを効果的に管理することは、特に複雑さが増すにつれて、APIプロジェクトをクリーンでスケーラブル、かつ維持しやすい状態に保つための鍵となります。シンプルな単一サービスプロジェクトに取り組んでいる場合でも、大規模なマイクロサービスアーキテクチャに取り組んでいる場合でも、Apidogはワークフローに適応する柔軟なオプションを提供します。
サービスをモジュールに整理し、環境ごとにベースURLを設定することで、各エンドポイントが常に正しいサーバーを指すようにし、手動での手間を省くことができます。スマートなデフォルト設定、環境切り替え、モジュール設計により、Apidogはプロセスを簡素化し、推測作業を不要にします。