Construindo um proxy de API simples

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Esta página se aplica ao Apigee e ao Apigee híbrido .

Veja a documentação do Apigee Edge .

A Apigee permite que você exponha rapidamente serviços de back-end como APIs. Para isso, crie um proxy de API que forneça uma fachada para o serviço de back-end que você deseja expor. Você precisa fornecer apenas o endereço de rede do serviço de back-end, juntamente com algumas informações que a Apigee usa para criar o proxy de API que será exposto aos desenvolvedores.

O proxy de API desvincula a implementação do seu serviço de backend da API que os desenvolvedores consomem. Isso protege os desenvolvedores de futuras alterações nos seus serviços de backend. À medida que você atualiza os serviços de backend, os desenvolvedores, protegidos dessas alterações, podem continuar a chamar a API sem interrupções.

Este tópico fornece informações sobre os vários tipos de proxies e suas configurações. Para obter instruções passo a passo sobre como criar proxies, consulte os seguintes tópicos:

• Tutorial: Crie seu primeiro proxy de API
• Criando um proxy de API

Criando um proxy de API usando a interface do usuário

A maneira mais fácil de criar um proxy de API é usar o assistente Criar Proxy .

Para acessar o assistente Criar proxy usando a interface do usuário do Apigee, execute as seguintes etapas:

1. Faça login na interface do usuário do Apigee .
2. Na barra de navegação, selecione Desenvolver > Proxies de API .
3. Clique em Criar novo .
   

O assistente Criar proxy exibe e orienta você pelas etapas para gerar e adicionar recursos mínimos a um proxy de API.

A primeira página do assistente permite que você crie um proxy de API a partir das seguintes fontes:

As seções a seguir discutem os detalhes de cada tipo de proxy.

Criando um proxy reverso para um serviço HTTP

O Apigee gera proxies reversos com base nas seguintes informações:

• URL do serviço de backend.
• Caminho URI que identifica exclusivamente a API que será exposta pelo proxy de API para aplicativos de consumidor.

A URL do serviço de backend normalmente representa um aplicativo habilitado para serviço de propriedade da sua organização. Também pode apontar para uma API disponível publicamente. A API ou serviço pode estar sob seu controle (por exemplo, um aplicativo interno de RH ou um aplicativo Rails na nuvem) ou pode ser uma API ou serviço de terceiros (por exemplo, Twitter ou Instagram).

Os seguintes detalhes do proxy estão disponíveis após acessar o assistente Criar proxy e selecionar um tipo de proxy :

Importando um proxy de API de um pacote de proxy de API

Frequentemente, você define proxies de API como uma coleção de arquivos XML, juntamente com quaisquer outros arquivos de suporte. Ao definir seus proxies de API como um conjunto de arquivos externos à Apigee, você pode mantê-los em um sistema de controle de origem e, em seguida, importá-los para a Apigee para testes e implantação.

Para importar proxies de API de um pacote de proxy de API, execute as seguintes etapas:

1. Acesse o assistente Criar proxy conforme descrito anteriormente em Criar um proxy de API usando a interface do usuário nesta seção.
2. Clique em Carregar pacote proxy .

3. Na página Carregar pacote de proxy no assistente de proxy, insira as seguintes informações:

   Campo	Descrição
   Pacote ZIP	Arquivo ZIP contendo a configuração do proxy da API. Arraste e solte ou clique para navegar até o arquivo.
   Nome	Nome exibido para sua API. O padrão é o nome do arquivo ZIP sem a extensão.

4. Clique em Avançar .

5. Na página Resumo , selecione os ambientes de implantação, se desejar, e clique em Criar e implantar

   Uma confirmação será exibida confirmando que seu novo proxy de API foi criado com sucesso.

6. Clique em Editar proxy para exibir a página de detalhes do proxy da API.

Criação de proxies de API gRPC

Neste momento, os proxies da API gRPC da Apigee:

• Suporte a solicitações gRPC unárias.
• Não é possível usar políticas que afetam a carga útil.
• Pode ser usado em produtos de API que não estejam associados a proxies GraphQL ou REST. Cotas específicas do produto de API e outras configurações de operação se aplicam a todos os proxies do produto.
• Não são compatíveis com o Apigee híbrido.
• Use duas variáveis ​​de fluxo específicas do gRPC: request.grpc.rpc.name e request.grpc.service.name .
• Pode ser monitorado com estas variáveis ​​do Apigee Analytics específicas do gRPC: x_apigee_grpc_rpc_name , x_apigee_grpc_service_name e x_apigee_grpc_status .
• Retornar códigos de status gRPC .

Você também precisa configurar seu balanceador de carga para oferecer suporte ao gRPC. Consulte Usando o gRPC com seus aplicativos e Usando comandos da CLI do gcloud para criar roteamento para gRPC .

Para criar um proxy de API gRPC, primeiro defina um servidor de destino gRPC (consulte Criando TargetServers ) e depois especifique esse servidor de destino ao criar o novo proxy.

Usando comandos CLI do gcloud para criar roteamento para gRPC

Esta seção mostra exemplos de comandos para criar roteamento para proxies gRPC usando a CLI gcloud . As instruções incluem a configuração de balanceadores de carga, um servidor de destino e um MIG.

Esta seção não é um guia completo para a criação do roteamento. Estes exemplos podem não ser adequados para todos os casos de uso. Além disso, estas instruções pressupõem familiaridade com o Roteamento Externo (MIG) e a configuração gRPC do Cloud Load Balancer .

Definir variáveis ​​de ambiente

Essas variáveis ​​de ambiente são usadas nos comandos nas subseções.

PROJECT_ID=YOUR_PROJECT_ID
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=default
VPC_SUBNET=default
REGION=REGION_NAME
APIGEE_ENDPOINT=ENDPOINT
CERTIFICATE_NAME=CERTIFICATE_NAME
DOMAIN_HOSTNAME=DOMAIN_HOSTNAME

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 50 \
--target-cpu-utilization 0.75 --cool-down-period 90

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

gcloud compute addresses create lb-ipv4-vip-1 \
--project $PROJECT_ID \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global

  gcloud compute addresses describe lb-ipv4-vip-1 \
--project $PROJECT_ID --format="get(address)" --global

  gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \
--project $PROJECT_ID --address lb-ipv4-vip-1 --global \
--target-https-proxy apigee-envoy-https-proxy --ports 443

gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

# Create backend service for http2
    gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

gcloud compute url-maps list -project $PROJECT_ID

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2
weight: 100

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

Adicionando segurança

Na página Políticas comuns do assistente Criar proxy , selecione o tipo de autorização de segurança que deseja adicionar. A tabela a seguir resume as opções disponíveis:

Adicionando suporte para CORS

O compartilhamento de recursos entre origens (CORS) é um mecanismo padrão que permite que um navegador da web faça solicitações diretas a outro domínio. O padrão CORS define um conjunto de cabeçalhos HTTP que navegadores e servidores da web usam para implementar a comunicação entre domínios.

Você pode adicionar suporte ao CORS seguindo um destes procedimentos:

• Adicionando a política CORS ao PreFlow de solicitação do ProxyEndpoint
• Selecionando Adicionar cabeçalhos CORS na página Políticas comuns do assistente Criar proxy

Para obter informações mais detalhadas sobre o suporte a CORS, incluindo a adição de suporte a pré-voo a CORS a um proxy, consulte Adicionando suporte a CORS a um proxy de API .

Adicionando cotas

As cotas protegem seu serviço de backend contra tráfego intenso sob a Cota . Consulte Cotas . (Não disponível se a autorização de passagem estiver selecionada.)

Usando especificações OpenAPI para gerar proxies

Esta seção discute a opção Usar OpenAPI que está disponível para gerar a partir de uma Especificação OpenAPI os seguintes tipos de proxies de API: reverso ou sem destino.

O que é uma especificação OpenAPI?

A Open API Initiative (OAI) concentra-se em criar, desenvolver e promover um formato de descrição de API neutro em relação a fornecedores, baseado na Especificação Swagger. Para mais informações, consulte a OpenAPI Initiative .

Uma Especificação OpenAPI usa um formato padrão para descrever uma API RESTful. Escrita em formato JSON ou YAML, uma Especificação OpenAPI é legível por máquinas, mas também é fácil para humanos lerem e entenderem. A especificação descreve elementos da API, como seu caminho base, caminhos e verbos, cabeçalhos, parâmetros de consulta, operações, tipos de conteúdo, descrições de resposta e muito mais. Além disso, uma Especificação OpenAPI é comumente usada para gerar documentação de API.

O fragmento a seguir de uma especificação OpenAPI descreve o serviço de destino simulado da Apigee, http://mocktarget.apigee.net . Para obter mais informações, consulte a especificação OpenAPI para o exemplo helloworld .

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

Com o assistente "Criar Proxy" , você pode importar uma Especificação OpenAPI e usá-la para gerar um proxy de API. Após a geração do proxy, você pode usar a interface de usuário da Apigee para desenvolvê-lo ainda mais, adicionando políticas, implementando código personalizado e assim por diante, como qualquer proxy da Apigee.

Criando um proxy de API a partir de uma especificação OpenAPI

Crie seus proxies de API a partir de uma especificação OpenAPI. Em apenas alguns cliques, você terá um proxy de API com caminhos, parâmetros, fluxos condicionais e endpoints de destino gerados automaticamente. Em seguida, você pode adicionar recursos como segurança OAuth, limitação de taxa e cache.

No assistente "Criar Proxy" , clique em "Usar Especificação OpenAPI" e siga as instruções do assistente para criar um proxy reverso ou sem destino a partir de uma Especificação OpenAPI. Para obter mais detalhes, consulte "Criar um proxy de API a partir de uma Especificação OpenAPI" .

Criando uma nova revisão de um proxy de API

Crie uma nova revisão de um proxy de API, conforme descrito abaixo.

Para criar uma nova revisão de um proxy de API, execute as seguintes etapas:

1. Faça login na interface do usuário do Apigee .
2. Na barra de navegação, selecione Desenvolver > Proxies de API .
3. Clique no proxy de API na lista que você deseja copiar.

4. Clique na aba Desenvolver .

5. Selecione o botão Salvar e selecione Salvar como nova revisão .

Fazendo backup de um proxy de API

Você pode fazer backup de um proxy de API existente como um conjunto de arquivos XML em um pacote de proxy de API. Após a exportação para um pacote, você pode importar o proxy de API para um novo proxy, conforme descrito em Importando um proxy de API de um pacote de proxy de API, anteriormente nesta seção. Para obter mais informações, consulte Baixar proxies de API .

Criando um proxy de API usando a API

Para criar um proxy de API usando a API, consulte Criando um proxy de API .

Sobre proxies sem alvo

Nenhum proxy de destino na Apigee é útil quando você deseja processar solicitações dentro da própria Apigee sem encaminhá-las para um serviço de back-end. É importante entender quando essa abordagem é apropriada.

Casos de uso comuns

• Interação com dados gerenciados pela Apigee : um proxy sem destino é útil nos casos em que você só precisa interagir com dados gerenciados pela Apigee, como dados armazenados em um mapa de chave-valor (KVM) ou no cache da Apigee . Por exemplo, você pode usar um proxy sem destino para recuperar dados, como dados de sessão do usuário ou dados de configuração, da KVM. Nesse caso, não há necessidade de chamar um serviço de back-end. Tudo o que é necessário é uma política KeyValueMapOperations no fluxo do proxy. Para outro exemplo, você pode querer que o chamador solicite que um cache seja liberado. Você pode fazer isso invocando a política InvalidateCache , sem precisar se conectar a um destino.
• Usando APIs simuladas : você pode criar APIs simuladas para simular o comportamento da API antes da conclusão da implementação do backend, permitindo que o desenvolvimento do frontend progrida de forma independente. Para saber mais sobre como criar APIs simuladas, consulte OpenAPI Mock API Proxy no GitHub.
• Gerenciamento de tokens : a Apigee pode emitir tokens OAuthV2, e isso geralmente é feito por meio de um proxy sem destino.
• Testando o comportamento da política : um proxy sem destino pode ser útil quando você deseja testar o comportamento das políticas da Apigee.