The exception to this recommendation is when you are using Google App Engine as
a backend. When using App Engine, a DNS entry with the name PROJECT-ID.appspot.com
is automatically created for your service. Although you can certainly use the
*.cloud.goog naming pattern, you may prefer the naming
pattern PROJECT-ID.appspot.com so that the service name and the FQDN are the
same.

Depending on the purpose of the environment or the stage in the API lifecycle,
you may want to:

Change the API name.

Create a different project.

Change the path that the API is served from.

Following are some common patterns you may want to use:

Versioning the API: When you think you may need to make backwards-incompatible
changes in the future, plan ahead and add the version number in the path where
the API is served from. For example:

Running a private alpha: When you want to test a new version of your
service with some customers, but not all, the easiest approach is to put the
alpha version in its own project, which provides the highest level of isolation
from production. For example:

my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo

Alternatively, you could put the alpha version in the same project but
configure it as a separate service. Since it is a separate service, you can
restrict access to only the alpha customers. For example:

my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo

Running an open alpha: When you want to release an alpha version that
is available to all customers, you can put it in the same service and project as
the existing version, and change the path. For example: