Entendendo as Três Arquiteturas do API Gateway
O AWS API Gateway oferece três modelos distintos para expor suas aplicações: REST API, HTTP API e WebSocket API. Cada uma serve a um propósito específico e escolher a correta impacta diretamente na performance, custo e capacidade de manutenção em produção. A REST API é a mais tradicional e robusta, ideal para aplicações complexas que precisam de recursos avançados como autorização granular e transformação de requisições. A HTTP API é uma versão otimizada e mais barata, perfeita para microsserviços simples e APIs modernas. A WebSocket API permite comunicação bidirecional em tempo real, essencial para chats, notificações push e dashboards ao vivo.
Em produção, você raramente usará apenas uma. Uma arquitetura típica combina REST API para operações CRUD tradicionais e WebSocket para notificações em tempo real. O HTTP API fica reservado para endpoints de alto volume com lógica simples. Entender quando usar cada uma é a primeira decisão arquitetural crítica.
REST API: O Padrão Robusto para Produção
A REST API é a escolha natural para a maioria das aplicações corporativas. Ela oferece controle fino sobre autenticação, autorização, limitação de taxa, validação de schemas e transformação de requisições. Seu custo é ligeiramente maior, mas a segurança e flexibilidade justificam para sistemas que processam dados sensíveis.
# Exemplo de configuração REST API com CloudFormation
AWSTemplateFormatVersion: '2010-09-09'
Resources:
MyRestApi:
Type: AWS::ApiGateway::RestApi
Properties:
Name: ProdutoAPI
Description: API REST em Produção
EndpointConfiguration:
Types:
- REGIONAL
ProdutosResource:
Type: AWS::ApiGateway::Resource
Properties:
RestApiId: !Ref MyRestApi
ParentId: !GetAtt MyRestApi.RootResourceId
PathPart: produtos
GetProdutosMethod:
Type: AWS::ApiGateway::Method
Properties:
RestApiId: !Ref MyRestApi
ResourceId: !Ref ProdutosResource
HttpMethod: GET
AuthorizationType: AWS_IAM
Integration:
Type: AWS_PROXY
IntegrationHttpMethod: POST
Uri: !Sub 'arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${ProdutosLambda.Arn}/invocations'
A integração com Lambda via proxy (AWS_PROXY) é o padrão recomendado em 2024. Ela passa toda a requisição HTTP como evento para a função Lambda, permitindo que você processe Headers, Query Strings e Body sem transformações manuais no API Gateway. Implemente autenticação usando API Keys ou AWS IAM para endpoints críticos, e sempre ative logging CloudWatch para auditoria em produção.
HTTP API: Velocidade e Economia de Custo
A HTTP API é 71% mais barata que a REST API e possui latência significativamente menor. Ideal quando você precisa apenas das operações básicas HTTP sem recursos avançados como mapeamento de modelos ou autorização granular. Para microsserviços e APIs públicas de alto volume, ela é a escolha óbvia.
// Exemplo de Lambda integrado com HTTP API
export const handler = async (event) => {
console.log('Event:', JSON.stringify(event, null, 2));
try {
// HTTP API passa o corpo como string
const body = typeof event.body === 'string'
? JSON.parse(event.body)
: event.body;
if (!body.nome || !body.preco) {
return {
statusCode: 400,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ erro: 'Nome e preço são obrigatórios' })
};
}
// Simular salvamento no banco
const produto = {
id: Math.random().toString(36).substr(2, 9),
...body,
dataCriacao: new Date().toISOString()
};
return {
statusCode: 201,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(produto)
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ erro: 'Erro ao processar requisição' })
};
}
};
Configure a HTTP API via Terraform para produção com stage variables que separam ambientes:
resource "aws_apigatewayv2_api" "http_api" {
name = "produtos-api-http"
protocol_type = "HTTP"
cors_configuration {
allow_origins = ["https://seu-dominio.com"]
allow_methods = ["GET", "POST", "PUT", "DELETE"]
allow_headers = ["Content-Type", "Authorization"]
}
}
resource "aws_apigatewayv2_stage" "prod" {
api_id = aws_apigatewayv2_api.http_api.id
name = "prod"
auto_deploy = true
default_route_settings {
throttling_burst_limit = 5000
throttling_rate_limit = 2000
}
}
WebSocket API: Comunicação Real-Time em Escala
A WebSocket API mantém conexões persistentes, permitindo que o servidor envie mensagens ao cliente sem esperar por requisições. Essencial para chats, notificações em tempo real e colaboração ao vivo. A complexidade está em gerenciar o ciclo de vida das conexões: connect, message e disconnect.
# Lambda para manipular eventos WebSocket
import json
import boto3
import os
apigateway_client = boto3.client('apigatewayv2')
CONNECTION_TABLE = os.environ['CONNECTION_TABLE']
dynamodb = boto3.resource('dynamodb')
def lambda_handler(event, context):
route_key = event['requestContext']['routeKey']
connection_id = event['requestContext']['connectionId']
if route_key == '$connect':
# Armazenar conexão ativa
table = dynamodb.Table(CONNECTION_TABLE)
table.put_item(Item={'connectionId': connection_id})
return {'statusCode': 200}
elif route_key == '$disconnect':
# Remover conexão encerrada
table = dynamodb.Table(CONNECTION_TABLE)
table.delete_item(Key={'connectionId': connection_id})
return {'statusCode': 200}
elif route_key == 'sendMessage':
# Broadcast para todos os clientes conectados
body = json.loads(event['body'])
table = dynamodb.Table(CONNECTION_TABLE)
connections = table.scan()['Items']
for conn in connections:
try:
apigateway_client.post_to_connection(
ConnectionId=conn['connectionId'],
Data=json.dumps({
'tipo': 'mensagem',
'conteudo': body['mensagem'],
'timestamp': int(time.time())
})
)
except Exception as e:
print(f"Erro ao enviar para {conn['connectionId']}: {str(e)}")
return {'statusCode': 200}
A estratégia de armazenar IDs de conexão no DynamoDB é essencial. Configure o TTL automático para evitar dados obsoletos de conexões que não desconectaram corretamente. Para aplicações com milhões de conexões simultâneas, considere usar sharding ou Redis para armazenar conexões, não DynamoDB.
Padrões de Segurança e Deployment em Produção
Em produção, sempre implemente throttling e rate limiting no API Gateway, não confie apenas na Lambda. Configure custom domain names com certificados ACM para HTTPS e use WAF (Web Application Firewall) para bloquear ataques comuns. Implemente versionamento via stage variables para não quebrar clientes antigos ao fazer deploy de mudanças.
# Deployment seguro via AWS CLI
aws apigateway create-deployment \
--rest-api-id abc123 \
--stage-name prod \
--stage-variable version=v2 \
--description "Versão 2.0 com autenticação JWT"
# Monitorar CloudWatch
aws logs tail /aws/apigateway/ProdutoAPI --follow
Conclusão
Você aprendeu que REST API é para controle e segurança, HTTP API para velocidade e economia, e WebSocket API para real-time. Em produção, a decisão não é "qual usar", mas "como combinar as três". Use REST API como camada principal, HTTP API para endpoints de alto volume e WebSocket apenas quando necessário bidirecionalidade verdadeira. Sempre implemente throttling, logging e monitoramento desde o primeiro dia, pois problemas de API Gateway em produção afetam toda sua aplicação.