Notas da versão

Nesta página, apresentamos as notas da versão referentes a recursos e atualizações do Cloud Endpoints. Para informações sobre as atualizações do Extensible Service Proxy (ESP), consulte as Notas da versão do ambiente de execução do Endpoints no GitHub.

Para receber as atualizações de produtos mais recentes, adicione o URL desta página ao leitor de feeds.

Setembro de 2018

O Cloud Endpoints Frameworks v1 foi encerrado

O uso do Cloud Endpoints Frameworks v1 para o ambiente padrão do Google App Engine foi suspenso em 2 de agosto de 2017. O serviço foi encerrado em 13 de setembro de 2018 e a documentação foi removida.

Endpoints Frameworks para Python: como alterar o nível de geração de registros padrão

A capacidade de alterar o nível de geração de registros padrão foi adicionada ao Endpoints Frameworks para Python. Para ver mais informações, consulte Como fazer login no Endpoints Framework para Python.

Agosto de 2018

Atualizações do Portal do Cloud Endpoints

O Portal do Endpoints agora está com disponibilidade geral. Esta versão inclui os novos recursos e aprimoramentos a seguir:

Sincronizar a documentação personalizada por meio de uma API

Uma API que permite sincronizar a documentação personalizada para o portal agora está disponível. Para saber mais, consulte a documentação de implementação da API:

Incluir imagens na documentação personalizada

É possível adicionar imagens ao repositório Git de conteúdo personalizado e referenciá-las em arquivos Markdown. Para saber mais, consulte a documentação de implementação da API:

Introdução a documentação de referência da API SmartDocs

Documentação de referência da API SmartDocs é o nome do componente que exibe a documentação de referência da API no seu portal e fornece o painel Teste esta API. Originalmente desenvolvido para o Portal do Endpoints, o SmartDocs também está disponível no portal integrado do desenvolvedor da Apigee.

O encerramento do Cloud Endpoints Frameworks v1 está próximo

O uso do Cloud Endpoints Frameworks v1 para o ambiente padrão do Google App Engine foi suspenso em 2 de agosto de 2017. O serviço está programado para ser encerrado em 3 de setembro de 2018 e a documentação será removida. Para evitar uma indisponibilidade, migre seu aplicativo v1. Para ver informações sobre como migrar seu aplicativo para o Endpoints Frameworks v2, consulte estes guias:

Desativar a amostragem de rastreio no ESP

Por padrão, o ESP faz a amostragem de um pequeno número de solicitações para sua API e envia rastreamentos para o Stackdriver Trace. A opção de inicialização do ESP para desabilitar a amostragem de rastreamento foi adicionada à versão 1.19.0 do ESP. Essa opção agora está disponível para implantações no ambiente flexível do App Engine.

Para saber mais, consulte "Como rastrear sua API" na documentação de implementação da API:

O Endpoints Frameworks, usado no ambiente padrão do Google App Engine, não usa o ESP para o gerenciamento de APIs e não envia dados de rastreamento para o Stackdriver Trace.

Julho de 2018

Novo papel e permissões para o Portal do Endpoints

O papel Google Cloud Identity and Access Management (Cloud IAM), o Administrador do portal do Endpoints e várias permissões novas do Cloud IAM já estão disponíveis. O papel e permissões novos permitem que você controle o grau de acesso que os membros do projeto têm ao Portal do Cloud Endpoints.

Para saber mais, consulte "Permissões do Portal do Cloud Endpoints" na documentação de implementação da API:

Junho de 2018

Atualizações de bibliotecas e plug-ins

  • A biblioteca do Endpoints Frameworks para Python versão 4.4.0 foi aprimorada para que você importe message_types, messages e classes remote da biblioteca de endpoints em vez de protorpc. No arquivo de definição da API, recomendamos que você altere suas instruções de importação de:

    import endpoints
    from protorpc import message_types
    from protorpc import messages
    from protorpc import remote
    

    para:

    from endpoints import message_types
    from endpoints import messages
    from endpoints import remote
    

    Essa alteração opcional nas instruções de importação simplifica o código na biblioteca do Endpoints Frameworks.

  • Agora, o Endpoints Frameworks para bibliotecas Java versão 2.1.0 valida que as solicitações tenham parâmetros obrigatórios. Se um parâmetro obrigatório for omitido em uma solicitação, o Endpoints Frameworks retornará o código de status HTTP 400, Bad Request.

Lançamento Beta do Portal do Endpoints

Você usa o Portal do Cloud Endpoints para criar um portal de desenvolvedor, um site que os usuários da sua API Cloud Endpoints podem acessar para ler a documentação e interagir com a API.

Para saber mais, consulte "Visão geral do Portal do Cloud Endpoints" na documentação de implementação da API:

Março de 2018

Opção de implantação gerenciada no ESP

A opção --rollout_strategy=managed do ESP agora está disponível para APIs descritas com o OpenAPI ou gRPC. Com essa opção, o ESP é configurado para usar a implantação mais recente da configuração de serviço. Quando essa opção é especificada, a alteração é detectada pelo ESP até um minuto após a implantação de uma nova configuração de serviço e começa a ser usada automaticamente. Recomendamos especificar essa opção em vez de um código de configuração específico para uso do ESP.

Esta opção não está disponível no Endpoints Frameworks.

Embora a opção de implantação gerenciada esteja disponível no ESP a partir da versão 1.7.0, a ferramenta de linha de comando gcloud foi atualizada para disponibilizar a opção no ambiente flexível do App Engine. Atualmente, a opção está disponível apenas na versão Beta da ferramenta de linha de comando gcloud. Depois de adicionar a opção ao seu app.yaml, será necessário usar o comando gcloud beta app deploy para implantar sua API e o ESP.

Para mais informações sobre como implantar o ESP com essa nova opção, consulte a documentação de implementação da sua API:

Atualizações de bibliotecas e plug-ins

  • A biblioteca Endpoints Frameworks para Python, versão 3.0.0 contém alterações potencialmente importantes.
    • Agora é possível implantar um único serviço com várias APIs. No entanto, há restrições sobre nomes de API para usar essa funcionalidade. Para ver mais informações, consulte Como implantar e testar uma API.
    • Anteriormente, as strings da versão da API eram incorporadas sem alterações no caminho. Por exemplo, um echo da API com a versão v1 teria um caminho /echo/v1. Este continua a ser o caso de strings de versão da API não compatíveis com o padrão SemVer. Caso seja especificada uma string de versão compatível com padrão SemVer, o número da versão principal será identificado e incorporado no caminho da sua API no momento da implantação. Assim, por exemplo, uma API chamada echo com a versão 2.1.0 terá um caminho semelhante a /echo/v2. Caso você atualize a API echo para a versão 2.2.0 e implante uma alteração compatível com versões anteriores, o caminho permanecerá /echo/v2. Com essas ações, você atualiza o número da versão da API durante a alteração compatível com versões anteriores, sem alterar os caminhos atuais para seus clientes. No entanto, caso você atualize a API echo para a versão 3.0.0 pelo fato de estar implantando uma alteração importante, o caminho será alterado para /echo/v3.

Janeiro de 2018

Agora, o painel do Endpoints oferece a capacidade de comparar um arquivo de configuração com a versão anterior. Visualizar as diferenças nos arquivos de configuração pode ser útil ao solucionar um problema com uma implantação específica. Para saber mais, consulte a documentação de implementação da API:

Atualizações de bibliotecas e plug-ins

  • Biblioteca do Endpoints Framework para Python, versão 2.5.0

Dezembro de 2017

Endpoints DNS

Agora, o recurso Endpoints DNS está com disponibilidade geral. Você pode configurar o Endpoints para registrar um URL que pode se usado para chamar as APIs. Para pessoas que não usam o App Engine, isso fornece uma maneira conveniente de chamar APIs sem usar seu endereço IP ou registrar um nome de domínio. A API pode ser chamada com um URL, como:

echo-api.endpoints.my-project-id.cloud.goog

Para saber mais, consulte a página "Como configurar o DNS no domínio cloud.goog" na documentação de implantação da API:

Endpoints DNS com SSL

Agora está disponível uma amostra que demonstra como ativar o SSL para APIs configuradas para usar o domínio cloud.goog. Para saber mais, consulte a documentação de implementação da API:

Novembro de 2017

Filtrar por um projeto de consumidor específico

A capacidade de filtrar métricas por um projeto de consumidor específico está disponível como recurso Alfa no painel do Endpoints. Para saber mais, consulte a documentação de implementação da API:

Atualizações de bibliotecas e plug-ins

  • Biblioteca do Endpoints Framework para Python, versão 2.4.5

  • Plug-in Endpoints Framework Gradle, versão 1.0.3

  • Plug-in Endpoints Framework Maven, versão 1.0.3

Outubro de 2017

Lançamento beta de cotas

As cotas permitem especificar os limites de uso para proteger a API de um número excessivo de solicitações. Para saber mais sobre cotas, consulte a página "Sobre cotas" na documentação da implementação da API:

gcloud endpoints e gcloud services

Os grupos de comando do SDK do Cloud gcloud endpoints e gcloud services agora estão com disponibilidade geral. Os grupos de comandos gcloud endpoints e gcloud services substituem o gcloud service-management, que está obsoleto.

Atualizações de biblioteca

  • A biblioteca do Endpoints Frameworks para Python, versão 2.4.1 está disponível.

  • As bibliotecas do Endpoints Frameworks para Java, versão 2.0.9 estão disponíveis.

Agosto de 2017

As métricas de API agora são publicadas no Stackdriver. Você pode monitorar taxas de solicitação, latências e muito mais. Para informações sobre a configuração de alertas, consulte a página "Como monitorar a API" na documentação da implementação da API:

Você encontra uma lista completa de métricas na lista de métricas do Stackdriver.

Julho de 2017

Agora você pode conceder acesso a APIs individuais programaticamente por meio da IAM API. Consulte a página "Visão geral do acesso à API" referente à implementação da API para saber detalhes.

Maio de 2017

O Endpoints agora atribui chamadas ao projeto produtor quando nenhuma chave de API é fornecida e relata o protocolo usado pelo back-end (gRPC, HTTP).

Abril de 2017

Com o Endpoints, agora é possível registrar uma URL para chamar suas APIs. Para aqueles que não usam o App Engine, essa é uma maneira conveniente de chamar APIs sem usar o endereço IP. A API pode ser chamada com uma URL, como:

echo-api.endpoints.my-project-id.cloud.goog

Para saber mais detalhes, consulte a página de configuração da OpenAPI ou a do gRPC.

Fevereiro de 2017

Agora, o Histórico de implantações da API está disponível no Google Cloud Console, permitindo ver o histórico de implantações de configuração da API. Essa funcionalidade está atualmente na versão beta.

O histórico de implantações da API mostra quem carregou determinada configuração, quando ela foi carregado e qual o código da configuração. Isto é útil para encontrar os códigos de configuração e a atribuição de alterações de configuração para sua API.

Para ver a nova tela, navegue até a API na seção IU do Endpoints do console do Cloud e clique na guia "Histórico de implantações".

Janeiro de 2017

Estamos mudando o comportamento do Extensible Service Proxy (ESP) para negar solicitações de compartilhamento de recursos entre origens (CORS, na sigla em inglês) por padrão. Se você depende de solicitações CORS, precisa alterar sua configuração para permiti-las explicitamente e reimplantar até 2 de janeiro de 2017.

Contexto e comportamento atual

Com o CORS padrão, um navegador insere uma solicitação OPTIONS extra para o servidor a fim de determinar se ele tem permissão para fazer uma solicitação entre origens. Atualmente, o ESP sempre aceita solicitações OPTIONS. Isso significa que, atualmente, o ESP sempre permite solicitações entre origens por meio de CORS.

Próximas mudanças

O ESP permitirá que produtores de serviços especifiquem se desejam ou não permitir o tráfego entre origens. Por padrão, o ESP bloqueia as solicitações entre origens ao rejeitar todas as solicitações OPTIONS. Para permitir solicitações entre origens na API, adicione o snippet a seguir à configuração da OpenAPI do serviço.

...
"host": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
"x-google-endpoints": [
  {
    "name": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
    "allowCors": true
  }
],
...

O que você precisa fazer

Siga as instruções na guia apropriada a seguir.

App Engine Flex

Depois do lançamento do ESP 1.0 em 2 de janeiro de 2017, todas as implantações da Flexible Environment API contarão com a nova versão do ESP e deixarão de permitir solicitações CORS automaticamente. Os aplicativos do App Engine são reimplantados automaticamente a cada 7 dias. Assim, em algum momento dos 7 dias após o lançamento do ESP 1.0, seu app será reiniciado com a versão mais recente e estará protegido automaticamente contra o compartilhamento involuntário entre origens.

Se você estiver usando o Flex Environments e quiser continuar a permitir solicitações CORS, precisa adicionar o snippet "x-google-endpoints" acima à configuração da API (também conhecida como especificação OpenAPI ou arquivo Swagger). Se você depende de CORS, recomendamos adicionar o snippet assim que possível e reimplementar o serviço usando o comando a seguir para evitar a interrupção do serviço. Com ele, você não perceberá alteração no comportamento quando a nova versão do ESP for implementada.

gcloud app deploy app.yaml

Kubernetes Engine

Pretendemos introduzir essa alteração na versão 1.0 do ESP em 2 de janeiro de 2017.

Se estiver usando CORS atualmente para permitir o tráfego entre origens para sua API, terá que fazer alterações na configuração da API (também conhecida como especificação OpenAPI ou arquivo Swagger) ao fazer upgrade do ESP para a versão 1.0 após 2 de janeiro. Adicione os snippets "x-google-endpoints" acima à configuração OpenAPI da API e reimplante essa configuração com o comando a seguir.

gcloud service-management deploy openapi.yaml

Observe que a etapa acima enviou sua nova configuração de serviço para o gerenciador de serviços. Anote o novo SERVICE_CONFIG_ID, você precisará dele na próxima etapa.

Agora você precisa reimplantar seu serviço. É possível usar o comando a seguir, substituindo ESP-DEPLOYMENT pelo nome da implantação do serviço.

kubectl edit deployment/ESP-DEPLOYMENT

Este comando abre seu YAML de configuração do GKE e permite que você atualize a implantação. Certifique-se de alterar a versão do ESP para 1.0, atualizar SERVICE_CONFIG_ID com o novo código e salvar a implantação.

containers:
    - name: esp
      image: gcr.io/endpoints-release/endpoints-runtime:1.0
      args: [
        "--http_port", "8080",
        "--backend", "localhost:8081",
        "--service", "SERVICE_NAME",
        "--version", "SERVICE_CONFIG_ID",
      ]

Google Compute Engine

Pretendemos introduzir essa alteração na versão 1.0 do ESP em 2 de janeiro de 2017.

Se estiver usando CORS atualmente para permitir o tráfego entre origens para sua API, terá que fazer alterações na configuração da API (também conhecida como especificação OpenAPI ou arquivo Swagger) ao fazer upgrade do ESP para a versão 1.0. Adicione os snippets "x-google-endpoints" acima à configuração OpenAPI da API e reimplante essa configuração com o comando a seguir.

gcloud service-management deploy openapi.yaml

Observe que a etapa acima enviou sua nova configuração de serviço para o gerenciador de serviços. Anote o novo SERVICE_CONFIG_ID, você precisará dele na próxima etapa.

Antes de reimplantar seu serviço, você precisa atualizar as entradas de metadados na VM com o seguinte comando:

gcloud compute instances add-metadata --metadata=endpoints-service-name=SERVICE_NAME,endpoints-service-config-id=SERVICE_CONFIG_ID

Em seguida, você precisa introduzir o SSH na VM e executar o comando a seguir para reiniciar o ESP.

sudo /etc/init.d/nginx restart

Como alternativa, se você usar o script start_esp.py para iniciar o ESP (em vez do script init.d), poderá parar o ESP e executar o comando start_esp.py novamente com o "SERVICE_CONFIG_ID" atualizado.

Compute Engine + Docker

Pretendemos introduzir essa alteração na versão 1.0 do ESP em 2 de janeiro de 2017.

Se estiver usando CORS atualmente para permitir o tráfego entre origens para sua API, terá que fazer alterações na configuração da API (também conhecida como especificação OpenAPI ou arquivo Swagger) ao fazer upgrade do ESP para a versão 1.0. Adicione os snippets x-google-endpoints acima à configuração da OpenAPI da API e reimplante a configuração da API usando o comando a seguir.

gcloud service-management deploy openapi.yaml

Isso envia a nova configuração do serviço para o Google Service Management. Esse comando retorna um novo SERVICE_CONFIG_ID referente à API. Anote-o, você precisará dele na próxima etapa.

Em seguida, reimplante o serviço. Primeiro, pare e remova a instância atual do ESP (por exemplo, "esp") usando os comandos a seguir. Você pode usar o comando sudo docker ps para descobrir a instância atual do ESP.

sudo docker stop esp
sudo docker rm esp

Depois, execute o comando a seguir para reimplantar o ESP. Certifique-se de usar o novo SERVICE_CONFIG_ID para a opção -v.

sudo docker run --name=esp -d -p 80:8080 --link=echo:echo gcr.io/endpoints-release/endpoints-runtime:1.0 -s [SERVICE_NAME] -v [SERVICE_CONFIG_ID] -a echo:8081
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.