Nesta página, apresentamos recomendações para convenções de nomenclatura dos projetos do Cloud de que talvez você precise para criar além do que já está como back-end de produção.
Dependendo da finalidade do ambiente ou da etapa no ciclo de vida da API, é possível:
Alterar o nome da API ou o nome do serviço do Cloud Endpoints. Para mais informações, veja Como configurar o Endpoints.
Criar um projeto diferente.
Alterar o caminho de transmissão da API.
Estes são alguns padrões comuns que você pode querer usar:
Controle de versões da API: se houver alguma possibilidade de você precisar fazer alterações incompatíveis com versões anteriores no futuro, antecipe-se e adicione o número da versão ao caminho de transmissão da API. Por exemplo:
my-api.endpoints.my‐project.cloud.goog/v1/echo
Instâncias de desenvolvimento/teste: cada desenvolvedor defende a própria versão do serviço, no próprio projeto. Por exemplo, o desenvolvedor Dan usa:
Execução de uma versão alfa particular: quando você quiser testar uma nova versão do serviço com alguns clientes, mas não todos, a abordagem mais fácil é colocar a versão alfa no projeto. Isso proporciona o mais alto nível de isolamento da produção. Por exemplo:
Outra opção é colocar a versão alfa no mesmo projeto, e configurá-la como um serviço separado. Por ser um serviço separado, é possível restringir o acesso apenas aos clientes alfa. Por exemplo:
Execução de uma versão alfa aberta: quando você quiser disponibilizar uma versão alfa para todos os clientes, coloque-a no mesmo serviço e no mesmo projeto que a versão existente e altere o caminho. Exemplo:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eThis page offers guidelines for naming conventions of Cloud projects related to API management, beyond just the production backend project.\u003c/p\u003e\n"],["\u003cp\u003eConsider creating different Cloud projects for development, staging, and alpha testing environments to isolate and manage API versions.\u003c/p\u003e\n"],["\u003cp\u003eVersioning APIs by including version numbers in the path (e.g., \u003ccode\u003e/v1/\u003c/code\u003e, \u003ccode\u003e/v2alpha/\u003c/code\u003e) is recommended to facilitate backward-incompatible changes.\u003c/p\u003e\n"],["\u003cp\u003eRunning private alpha tests of APIs is suggested to use a separate Cloud project for enhanced isolation, or alternatively, a distinct service within the same project with restricted access.\u003c/p\u003e\n"],["\u003cp\u003eOpen alpha tests can be done within the existing service and project, by simply altering the API path to indicate the alpha version.\u003c/p\u003e\n"]]],[],null,["# Planning Your Cloud Projects\n\nOpenAPI \\| [gRPC](/endpoints/docs/grpc/planning-cloud-projects \"View this page for the Cloud Endpoints gRPC docs\")\n\n\u003cbr /\u003e\n\nThis page provides recommendations for naming conventions of the Cloud projects\nthat you may need to create in addition to the Cloud project for your production\nbackend.\n\nDepending on the purpose of the environment or the stage in the API lifecycle,\nyou may want to:\n\n- Change the API name or the Cloud Endpoints service name. See [Configuring Endpoints](/endpoints/docs/openapi/configure-endpoints#service_name) for more information.\n- Create a different project.\n- Change the path that the API is served from.\n\nFollowing are some common patterns you may want to use:\n\n- **Versioning the API**: When you think you may need to make backwards-incompatible\n changes in the future, plan ahead and add the version number in the path where\n the API is served from. For example:\n\n - `my-api.endpoints.my‐project.cloud.goog/`**v1**`/echo`\n- **Development/test instances**: Each developer stands up their own version of the\n service, in their own project. For example, Dan the developer uses:\n\n - `my-api.endpoints.`**dan-dev-project**`.cloud.goog/v1/echo`\n- **Staging**: Before you deploy to production, you test your APIs on your\n staging backend, which is in its own project. For example:\n\n - `my-api.endpoints.`**my‐project-staging**`.cloud.goog/v1/echo`\n- **Running a private alpha**: When you want to test a new version of your\n service with some customers, but not all, the easiest approach is to put the\n alpha version in its own project, which provides the highest level of isolation\n from production. For example:\n\n - `my-api.endpoints.`**my‐project-alpha** `.cloud.goog/`**v2alpha**`/echo`\n\n Alternatively, you could put the alpha version in the same project but\n configure it as a separate service. Since it is a separate service, you can\n restrict access to only the alpha customers. For example:\n - **my-api-alpha** `.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n- **Running an open alpha**: When you want to release an alpha version that\n is available to all customers, you can put it in the same service and project as\n the existing version, and change the path. For example:\n\n - `my-api.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n\nSee also:\n\n\u003cbr /\u003e\n\n- [API lifecycle management](/endpoints/docs/openapi/lifecycle-management)\n- [Versioning an API](/endpoints/docs/openapi/versioning-an-api)"]]
