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:
my-api.endpoints.dan-dev-project.cloud.goog/v1/echo
Preparação: antes de implantar na produção, teste as APIs no back-end de preparação, que está no próprio projeto. Por exemplo:
my-api.endpoints.my‐project-staging.cloud.goog/v1/echo
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:
my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo
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:
my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo
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:
my-api.endpoints.my-project.cloud.goog/v2alpha/echo