このページでは、本番環境のバックエンド用以外の目的で Cloud プロジェクトを作成する必要が生じた場合を含めて、Cloud プロジェクトの命名規則に関する推奨事項を示します。
環境の目的または API ライフサイクルのステージに応じて、次の作業が必要になる場合があります。
- API 名または Cloud Endpoints サービス名を変更する。詳細については、Endpoints を構成するをご覧ください。
- 別のプロジェクトを作成する。
- API の提供に使用するパスを変更する。
使用可能な一般的なパターンをいくつか紹介します。
API のバージョニング: 下位互換性のない変更が将来的に必要になりそうな場合は、事前に計画を立て、API の提供に使用するパスにバージョン番号を追加します。例:
my-api.endpoints.my‐project.cloud.goog/v1/echo
開発 / テスト インスタンス: デベロッパーがそれぞれ個別のプロジェクトで独自のバージョンのサービスを立ち上げます。たとえば、Dan は次のような名前を使用します。
my-api.endpoints.dan-dev-project.cloud.goog/v1/echo
ステージング: 本番環境にデプロイする前に、独自のプロジェクト内にあるステージング バックエンドで API をテストします。例:
my-api.endpoints.my‐project-staging.cloud.goog/v1/echo
限定公開アルファ版の実行: すべてのユーザーではなく、一部のユーザーを対象に新しいバージョンのサービスをテストする場合は、そのアルファ版を独自のプロジェクト内に配置して（本番環境から可能な限り分離して）テストするのが特に簡単な方法です。例:
my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo
あるいは、アルファ版を同じプロジェクトに入れて、個別のサービスとして構成することもできます。個別のサービスであれば、アルファ版のユーザーのみにアクセスを制限できます。例:
my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo
公開アルファ版の実行: すべてのユーザーを対象としたアルファ版をリリースする場合は、既存のバージョンと同じサービスおよびプロジェクト内にアルファ版を配置し、パスを変更します。例:
my-api.endpoints.my-project.cloud.goog/v2alpha/echo