As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Padrões de roteamento de API Em ambientes de desenvolvimento ágil, equipes autônomas (por ex., esquadrões e tribos) possuem um ou mais serviços que incluem muitos microsserviços. As equipes expõem esses serviços como APIs para permitir que seus consumidores interajam com seu grupo de serviços e ações. Há três métodos principais para expor as APIs HTTP aos consumidores upstream usando nomes de host e caminhos: | | | **Method (Método** | **Descrição** | **Exemplo** | | --- |--- |--- | | [**Roteamento de nomes de host**](api-routing-hostname.md) | Exponha cada serviço como um nome de host. | `billing.api.example.com` | | [**Roteamento de caminhos**](api-routing-path.md) | Exponha cada serviço como um caminho. | `api.example.com/billing` | | [**Roteamento com base no cabeçalho**](api-routing-http.md) | Exponha cada serviço como um cabeçalho HTTP. | `x-example-action: something` | Esta seção descreve os casos de uso típicos desses três métodos de roteamento e suas vantagens e desvantagens para ajudá-lo a decidir qual método se adapta melhor aos seus requisitos e estrutura organizacional. # Padrão de roteamento por nome de host O roteamento por nome de host é um mecanismo para isolar serviços de API, dando a cada API seu próprio nome de host; por exemplo, `service-a.api.example.com` ou `service-a.example.com`. ## Caso de uso típico O roteamento usando nomes de host reduz a quantidade de atrito nas versões, pois nada é compartilhado entre as equipes de serviço. As equipes são responsáveis por gerenciar tudo, desde entradas de DNS até operações de serviço em produção. ![\[Padrão de roteamento de nome de host para expor APIs HTTP aos consumidores upstream.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png) ## Prós O roteamento de nome de host é, de longe, o método mais simples e escalável para roteamento de API HTTP. É possível usar qualquer serviço AWS relevante para criar uma arquitetura que siga esse método ― você pode criar uma arquitetura com [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/), [Application Load Balancers](https://aws.amazon.com/elasticloadbalancing/) e [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) ou qualquer outro serviço compatível com HTTP. As equipes podem usar o roteamento de nome de host para possuir totalmente seu subdomínio. Também fica mais fácil isolar, testar e orquestrar implantações para Regiões da AWS específicos ou versões; por exemplo, `region.service-a.api.example.com` ou `dev.region.service-a.api.example.com`. ## Contras Quando você usa o roteamento de nome de host, seus consumidores precisam se lembrar de nomes de host diferentes para interagir com cada API que você expõe. Você pode mitigar esse problema fornecendo um SDK de cliente. No entanto, os SDKs do cliente vêm com seu próprio conjunto de desafios. Por exemplo, eles precisam oferecer suporte a atualizações contínuas, vários idiomas, versionamento, comunicação de alterações significativas causadas por problemas de segurança ou correções de bugs, documentação e assim por diante. Ao usar o roteamento de nome de host, você também precisa registrar o subdomínio ou domínio toda vez que criar um novo serviço. # Padrão de roteamento de caminhos O roteamento por caminhos é o mecanismo de agrupar várias ou todas as APIs sob o mesmo nome de host e usar um URI de solicitação para isolar serviços; por exemplo, `api.example.com/service-a` ou `api.example.com/service-b`. ## Caso de uso típico A maioria das equipes opta por esse método porque deseja uma arquitetura simples — um desenvolvedor precisa se lembrar de apenas uma URL, como `api.example.com`, para interagir com a API HTTP. A documentação da API geralmente é mais fácil de digerir porque geralmente é mantida em conjunto em vez de ser dividida em diferentes portais ou PDFs. O roteamento com base no caminho é considerado um mecanismo simples para compartilhar uma API HTTP. No entanto, envolve sobrecarga operacional, como configuração, autorização, integrações e latência adicional devido a vários saltos. Também requer processos maduros de gerenciamento de mudanças para garantir que uma configuração incorreta não interrompa todos os serviços. Em AWS, há várias maneiras de compartilhar uma API e rotear de forma eficaz para o serviço correto. As seções a seguir discutem três abordagens: proxy reverso de serviço HTTP, API Gateway e Amazon CloudFront. Nenhuma das abordagens sugeridas para unificar os serviços de API depende dos serviços posteriores em execução no AWS. Os serviços podem ser executados em qualquer lugar sem problemas ou com qualquer tecnologia, desde que sejam compatíveis com HTTP. ## Proxy reverso de serviço HTTP Você pode usar um servidor HTTP, como o [NGINX](https://www.f5.com/go/product/welcome-to-nginx), para criar configurações de roteamento dinâmico. Em uma arquitetura [Kubernetes](https://kubernetes.io/), você também pode criar uma regra de entrada para corresponder a um caminho para um serviço. (Este guia não aborda a entrada do Kubernetes; consulte a [documentação do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource) para obter mais informações.) A configuração a seguir para o NGINX mapeia dinamicamente uma solicitação HTTP de `api.example.com/my-service/` para `my-service.internal.api.example.com`. ``` server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } } ``` O diagrama a seguir ilustra o método de proxy reverso de serviço HTTP. ![\[Usando um proxy reverso de serviço HTTP para roteamento de caminhos.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png) Essa abordagem pode ser suficiente para alguns casos de uso que não usam configurações adicionais para iniciar o processamento de solicitações, permitindo que a API posterior colete métricas e registros. Para se preparar para a prontidão de produção operacional, você deve poder adicionar observabilidade para todos os níveis de sua pilha, adicionar configurações adicionais ou adicionar scripts para personalizar seu ponto de entrada de API para permitir atributos mais avançados, como limitação de taxa ou tokens de uso. ### Prós O objetivo final do método de proxy reverso de serviço HTTP é criar uma abordagem escalável e gerenciável para unificar APIs em um único domínio, de forma que pareça coerente para qualquer consumidor de API. Essa abordagem também permite que suas equipes de serviço implantem e gerenciem suas próprias APIs, com o mínimo de sobrecarga após a implantação. Serviços gerenciados AWS para rastreamento, como [AWS X-Ray](https://aws.amazon.com/xray/) ou [AWS WAF](https://aws.amazon.com/waf/), ainda são aplicáveis aqui. ### Contras A principal desvantagem dessa abordagem são os testes e o gerenciamento extensivos dos componentes de infraestrutura necessários, embora isso possa não ser um problema se você tiver equipes de engenharia de confiabilidade de sites (SRE) instaladas. Há um ponto de inflexão de custos com esse método. Em volumes baixos a médios, ele é mais caro do que alguns dos outros métodos discutidos neste guia. Em grandes volumes, é muito econômico (cerca de 100 mil transações por segundo ou mais). ## API Gateway O serviço [Amazon API Gateway](https://aws.amazon.com/api-gateway/) (APIs REST e APIs HTTP) pode rotear o tráfego de forma semelhante ao método de proxy reverso do serviço HTTP. Usar um gateway de API no modo proxy HTTP fornece uma maneira simples de agrupar muitos serviços em um ponto de entrada para o subdomínio de nível superior `api.example.com` e, em seguida, solicitações de proxy para o serviço aninhado; por exemplo, `billing.internal.api.example.com`. Provavelmente não é uma boa ideia ser muito granular mapeando todos os caminhos em todos os serviços no gateway de API raiz ou principal. Em vez disso, opte por caminhos curinga, como o `/billing/*`, para encaminhar solicitações para o serviço de cobrança. Ao não mapear todos os caminhos no gateway de API raiz ou principal, você ganha mais flexibilidade em relação às suas APIs, porque não precisa atualizar o gateway de API raiz a cada alteração da API. ![\[Roteamento de caminhos por meio do API Gateway.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png) ### Prós Para controlar fluxos de trabalho mais complexos, como alterar os atributos da solicitação, as APIs REST expõem a Linguagem de Modelo Apache Velocity (VTL) para permitir que você modifique a solicitação e a resposta. As APIs REST podem fornecer benefícios adicionais, como estes: + [Aut N/Z com AWS Identity and Access Management (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) ou [autorizadores AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) + [AWS X-Ray para rastreamento](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html) + [Integração com AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) + [Limitação de taxa básica](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + Tokens de uso para agrupar consumidores em diferentes níveis (consulte [Acelerar solicitações de API para obter melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) na documentação do API Gateway) ### Contras Em grandes volumes, o custo pode ser um problema para alguns usuários. ## CloudFront Você pode usar o [atributo de seleção dinâmica de origem](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) no [Amazon CloudFront](https://aws.amazon.com/cloudfront/) para selecionar condicionalmente uma origem (um serviço) para encaminhar a solicitação. Você pode usar esse atributo para rotear vários serviços por meio de um único nome de host, como `api.example.com`. ### Caso de uso típico A lógica de roteamento vive como código dentro da função Lambda@Edge, portanto, ela oferece suporte a mecanismos de roteamento altamente personalizáveis, como testes A/B, lançamentos canário, sinalização de atributo e reescrita de caminhos. Isso é ilustrado no diagrama a seguir. ![\[Roteamento de caminhos pelo CloudFront.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png) ### Prós Se você precisa armazenar em cache as respostas da API, esse método é uma boa maneira de unificar uma coleção de serviços em um único endpoint. É um método econômico para unificar coleções de APIs. Além disso, o CloudFront oferece suporte à [criptografia em nível de campo](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html), bem como à integração com o AWS WAF para limitação básica de taxa e ACLs básicas. ### Contras Esse método suporta no máximo 250 origens (serviços) que podem ser unificadas. Esse limite é suficiente para a maioria das implantações, mas pode causar problemas com um grande número de APIs à medida que você aumenta seu portfólio de serviços. Atualmente, a atualização das funções do Lambda@Edge leva alguns minutos. O CloudFront também leva até 30 minutos para concluir a propagação das alterações em todos os pontos de presença. Em última análise, isso bloqueia novas atualizações até que elas sejam concluídas. # Padrão de roteamento de cabeçalho HTTP O roteamento com base no cabeçalho permite direcionar o serviço correto para cada solicitação especificando um cabeçalho HTTP na solicitação HTTP. Por exemplo, enviar o cabeçalho `x-service-a-action: get-thing` permitiria `get thing` a partir de `Service A`. O caminho da solicitação ainda é importante, pois oferece orientação sobre em qual atributo você está tentando trabalhar. Além de usar o roteamento de cabeçalho HTTP para ações, você pode usá-lo como um mecanismo para roteamento de versões, habilitando sinalizadores de atributos, testes A/B ou necessidades semelhantes. Na realidade, você provavelmente usará o roteamento de cabeçalho com um dos outros métodos de roteamento para criar APIs robustas. A arquitetura do roteamento de cabeçalho HTTP normalmente tem uma fina camada de roteamento na frente dos microsserviços que encaminha para o serviço correto e retorna uma resposta, conforme ilustrado no diagrama a seguir. Essa camada de roteamento pode cobrir todos os serviços ou apenas alguns serviços para habilitar uma operação, como roteamento com base na versão. ![\[Roteamento de cabeçalho HTTP.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png) ## Prós As alterações de configuração exigem o mínimo esforço e podem ser automatizadas facilmente. Esse método também é flexível e oferece suporte a formas criativas de expor somente operações específicas que você desejaria de um serviço. ## Contras Assim como no método de roteamento de nome de host, o roteamento de cabeçalho HTTP pressupõe que você tenha controle total sobre o cliente e possa manipular cabeçalhos HTTP personalizados. Proxies, redes de entrega de conteúdo (CDNs) e balanceadores de carga podem limitar o tamanho do cabeçalho. Embora seja improvável que isso seja uma preocupação, pode ser um problema dependendo de quantos cabeçalhos e cookies você adiciona.