Para ter sua API gerenciada pelo Cloud Endpoints, você tem três opções, dependendo do local em que a API está hospedada e do tipo de protocolo de comunicação usado por ela:
- Cloud Endpoints para OpenAPI
- Cloud Endpoints para gRPC
- Cloud Endpoints Frameworks para o ambiente padrão do App Engine
Nesta página, descrevemos as opções do Endpoints para ajudá-lo a decidir qual é a opção certa para você.
Como escolher uma opção de computação
O Endpoints oferece suporte a diferentes opções de computação do Google Cloud que podem hospedar o código de back-end da API. O Endpoints funciona com o Extensible Service Proxy (ESP) ou com o Extensible Service Proxy V2 (ESPv2) para fornecer o gerenciamento de APIs. Na tabela a seguir, veja o resumo das opções de computação aceitas:
ESP para OpenAPI | ESP para gRPC | ESPv2 para OpenAPI | ESPv2 para gRPC | Endpoints Frameworks | |
---|---|---|---|---|---|
Ambiente padrão da geração 1 do App Engine |
Ambientes de execução do Java 8 e do Python 2.7 | ||||
Ambiente padrão da geração 2 do App Engine |
|||||
Ambiente flexível do App Engine |
|||||
Cloud Run functions | |||||
Cloud Run | |||||
Knative serving | |||||
Compute Engine | |||||
GKE | |||||
Kubernetes | |||||
Outro que não é do Google Cloud |
Para uma comparação dos recursos fornecidos pelo App Engine, pelo GKE e pelo Compute Engine, consulte Como escolher uma opção de computação. Se você está considerando usar o App Engine, precisa escolher o ambiente padrão ou flexível. Para uma comparação dos dois ambientes, consulte Como escolher um ambiente do App Engine.
Sobre as limitações de opções de computação
O Endpoints para OpenAPI e para gRPC podem usar ESP ou ESPv2 como um proxy. Nas plataformas sem servidor, o ESP ou o ESPv2 são implantados como um contêiner no seu aplicativo ou como um arquivo secundário do app. Para plataformas sem servidor, como Cloud Run, Cloud Functions e App Engine, o ESPv2 é implantado como um serviço do Cloud Run como um proxy remoto para gerenciar aplicativos de plataforma sem servidor.
Depois que você implanta o código de back-end da API, o ESP ou o ESPv2 intercepta todas as solicitações e executa as verificações necessárias (como autenticação) antes de encaminhar a solicitação ao back-end da API. Quando o back-end responde, o ESP coleta e informa a telemetria usando a Infraestrutura de serviços.
É possível conferir as métricas da API e os links para os registros e traces da Observabilidade do Google Cloud na página Serviços do Endpoints no console do Google Cloud.
Limitações do ambiente padrão da geração 1 do App Engine
O Endpoints do ambiente padrão da geração 1 do App Engine usavam o Endpoints Frameworks, que é compatível com apenas os ambientes de execução Java 8 e Python 2.7.
Como o ambiente padrão do App Engine não era compatível com implantações de vários contêineres quando o Endpoints Frameworks estava em desenvolvimento, o Endpoints Frameworks não usa o ESP. Em vez disso, ele inclui uma gateway de API integrada que oferece recursos de gerenciamento de API comparáveis aos recursos fornecidos pelo ESP para Endpoints para OpenAPI e Endpoints para gRPC.
As APIs gRPC não são compatíveis com o App Engine ou o Cloud Run
O gRPC é um framework de chamada de procedimento remoto (RPC) que pode ser executado em qualquer ambiente. Com o gRPC, um aplicativo cliente pode chamar métodos diretamente em um aplicativo servidor em uma outra máquina, como se fosse um objeto local. Um recurso principal do gRPC é o streaming bidirecional com transporte baseado em HTTP/2.
O App Engine e o Cloud Run functions não são compatíveis com HTTP/2.
Linguagens de programação compatíveis
- A especificação OpenAPI é independente de linguagem. É possível implementar sua API em qualquer linguagem de programação.
- O gRPC fornece o compilador de buffer de protocolo,
protoc
, para muitas das principais linguagens de programação: C ++, C#, Objective-C (para iOS), Dart, Go, Java, (incluindo compatibilidade com Android), Node.js, Python e Ruby. Consulte as Perguntas frequentes do gRPC para conferir a lista mais atualizada. - O Endpoints Frameworks só aceita Java 8 e Python 2.7.
Como descrever sua API
As opções do Endpoints oferecem maneiras diferentes de descrever sua API.
Endpoints para OpenAPI
A Iniciativa OpenAPI é um esforço de todo o setor para padronizar a descrição de APIs REST. O Endpoints é compatível com APIs descritas usando a versão 2.0 da especificação OpenAPI (anteriormente chamada de especificação Swagger). Você descreve a superfície da API em um arquivo JSON ou YAML (chamado de documento OpenAPI). É possível implementar a API usando qualquer framework REST publicamente disponível, como Django ou Jersey. Se você não estiver familiarizado com a especificação OpenAPI, consulte Visão geral da OpenAPI.
Para mais informações, consulte Endpoints para OpenAPI.
Endpoints para gRPC
Com o gRPC, você define a estrutura dos dados que quer serializar em um arquivo proto: este é um arquivo de texto comum com uma extensão .proto
. Você também
define a
superfície
da API em arquivos proto, com parâmetros de método RPC e tipos de retorno
especificados como mensagens de buffer de protocolo. Se você não conhece o gRPC, consulte
O que é o gRPC?
na documentação do gRPC.
Para mais informações, consulte Endpoints para gRPC.
Endpoints Frameworks
O Endpoints Frameworks é um framework da Web para os ambientes de execução padrão do Python 2.7 e Java 8 para App Engine. Você adiciona metadados (usando anotações em Java ou decoradores em Python) ao seu código-fonte. Os metadados descrevem a superfície das APIs REST do seu aplicativo.
Para mais informações, consulte Endpoints Frameworks.
A seguir
Veja os recursos do Endpoints em ação no Guia de início rápido do Cloud Endpoints, com uso de scripts para implantar uma API de amostra no ambiente flexível do App Engine.
Faça um dos tutoriais da opção escolhida do Endpoints para se familiarizar com as etapas de implantação:
Saiba mais sobre o Endpoints e o ESP: