API Gateway

API Gateway vs Reverse Proxy

A distinção é de camada de abstração e consciência de domínio. Um reverse proxy é agnóstico ao conteúdo que trafega — ele encaminha bytes HTTP sem entender o que significam. Um API Gateway entende APIs: sabe que GET /orders/{id} pertence ao serviço de pedidos, que requer o scope orders:read, que a key pública de um usuário tem quota de 1000 req/dia, e que a resposta deve ter o campo customerId mascarado para clientes de certos países.

Padrões de deployment

Edge Gateway — entrada única para APIs externas

O padrão mais comum: um único gateway na borda do sistema recebe todo o tráfego externo. Clientes (mobile, web, parceiros) acessam api.empresa.com e o gateway roteia para os serviços internos corretos. Centraliza autenticação, rate limiting e logging.

Internet
  ↓
api.empresa.com (DNS → Gateway)
  ↓ autenticação, rate limiting, logging
  ├→ /api/orders/*     → orders-service:8080
  ├→ /api/products/*   → products-service:8080
  ├→ /api/customers/*  → customers-service:8080
  └→ /api/payments/*   → payments-service:8080 (PCI zone)

BFF (Backend for Frontend)

O padrão BFF cria um gateway especializado por tipo de cliente — em vez de um gateway genérico para todos. O BFF mobile agrega dados de forma otimizada para telas pequenas com conexão instável; o BFF web pode retornar payloads mais ricos; o BFF de parceiros expõe apenas as APIs com contrato estável.

mobile-app.empresa.com  → BFF Mobile  → orders-service
                                        → products-service (campos reduzidos)
                                        → push-notification-service

web-app.empresa.com     → BFF Web     → orders-service
                                        → products-service (campos completos)
                                        → recommendations-service

partner-api.empresa.com → BFF Partner → orders-service (apenas status)
                                        → products-service (apenas catálogo público)

A vantagem do BFF é que cada equipe (mobile, web, parceiros) tem autonomia para otimizar seu gateway sem afetar os outros. A desvantagem é duplicação de lógica — autenticação, logging e circuit breaking precisam ser implementados em cada BFF.

Internal Gateway — entre microsserviços

Para comunicação service-to-service que precisa de autenticação de serviço, rate limiting por chamador, e observabilidade fina — sem a sobrecarga de um service mesh. Menos comum porque service meshes (Istio, Linkerd) resolvem o mesmo problema de forma mais transparente.

Micro-gateway / Sidecar Gateway

Cada serviço tem seu próprio gateway sidecar que gerencia o tráfego de entrada — autenticação, rate limiting e transformação específicos para aquele serviço. Utilizado quando os requisitos de gateway são muito específicos por serviço para compartilhar uma instância central.

Autenticação e Autorização

O API Gateway é o local natural para validar identidade antes que a requisição chegue ao backend — os serviços internos recebem requisições já autenticadas e podem confiar nos headers injetados pelo gateway (user-id, roles, scopes).

API Keys

O mecanismo mais simples: um token opaco gerado pelo gateway, associado a um cliente (aplicação, parceiro). O gateway valida a key em cada requisição, aplica as quotas e permissões do plano associado, e injeta o identificador do cliente no header X-Consumer-ID para logging.

# Exemplo de fluxo com API Key
Cliente → GET /api/products HTTP/1.1
          Authorization: ApiKey abc123xyz

Gateway:
1. Extrai "abc123xyz" do header Authorization
2. Lookup em Redis/banco: { consumer: "acme-corp", plan: "basic", quota_day: 1000, quota_used: 47 }
3. Verifica quota_used < quota_day
4. Incrementa quota_used atomicamente
5. Injeta headers para o backend:
   X-Consumer-ID: acme-corp
   X-Consumer-Plan: basic
   X-Rate-Limit-Remaining: 953
6. Encaminha para products-service

Backend recebe requisição com X-Consumer-ID — não precisa validar auth

OAuth 2.0 e JWT

Para APIs que autenticam usuários finais — não apenas aplicações — OAuth 2.0 com JWTs é o padrão. O gateway valida o token JWT (assinatura, expiração, issuer, audience) sem consultar o authorization server a cada requisição — a chave pública do AS é cacheada localmente.

# Validação de JWT no gateway (Kong, por exemplo)
# Plugin jwt ou openid-connect

# Fluxo completo:
1. Cliente obtém token do Authorization Server (auth.empresa.com)
   POST /oauth/token → { access_token: "eyJ...", expires_in: 3600 }

2. Cliente chama a API com o token
   GET /api/orders Authorization: Bearer eyJ...

3. Gateway valida localmente:
   - Verifica assinatura com chave pública JWKS (cacheada)
   - Verifica exp (não expirado)
   - Verifica iss = "auth.empresa.com"
   - Verifica aud = "api.empresa.com"
   - Extrai sub, scope, roles do payload

4. Gateway injeta no header para o backend:
   X-User-ID: user-abc123
   X-User-Roles: admin,orders:write
   X-User-Scopes: orders:read orders:write

5. Backend confia nos headers — não revalida o token

mTLS para APIs de parceiros

Para APIs B2B onde o cliente é uma empresa (não um usuário), mTLS oferece autenticação mútua baseada em certificados — sem senhas ou tokens que podem vazar. O gateway valida o certificado cliente (client certificate) e o associa a um consumer configurado.

# Kong — plugin mTLS auth
plugins:
- name: mtls-auth
  config:
    ca_certificates:
    - id: "uuid-do-certificado-CA-da-empresa-parceira"
    skip_consumer_lookup: false
    authenticated_group_by: "CN"  # usar o Common Name do cert como consumer ID

Autorização — o gateway decide o quê, o backend decide o como

Uma separação saudável: o gateway verifica se o cliente tem permissão para chamar o endpoint (scope orders:write presente no token, plano inclui o recurso). O backend verifica se o usuário tem permissão para a operação específica naquele dado (o pedido pertence ao usuário?). Não delegue decisões de negócio ao gateway — ele não conhece o estado da aplicação.

Rate Limiting e Quotas

Rate limiting no gateway protege os backends de sobrecarga e garante uso justo entre clientes. A implementação correta requer escolher o algoritmo certo e o nível de granularidade.

Algoritmos

Fixed Window Counter

Conta requisições em janelas fixas de tempo (ex: 100 req/minuto). A janela reseta a cada minuto. Simples de implementar com Redis INCR + TTL. Problema: boundary burst — um cliente pode fazer 100 req nos últimos segundos de uma janela e 100 req nos primeiros da próxima, efetivamente passando 200 req em alguns segundos.

# Redis — fixed window
local key = "rate_limit:" .. consumer_id .. ":" .. math.floor(now / 60)
local count = redis.incr(key)
if count == 1 then
    redis.expire(key, 60)  -- TTL de 1 minuto
end
if count > 100 then
    return 429  -- Too Many Requests
end

Sliding Window Log

Armazena o timestamp de cada requisição. Para verificar, conta quantas ocorreram na janela de 1 minuto terminando agora. Preciso — sem boundary burst — mas usa memória proporcional ao número de requisições por usuário.

Sliding Window Counter (aproximação)

Combina dois fixed windows para aproximar o sliding window: count = current_window_count + previous_window_count * (1 - elapsed/window_size). Eficiente em memória, boa aproximação sem armazenar timestamps individuais. É o algoritmo padrão do Redis Rate Limiting e do Kong.

Token Bucket

Um balde tem capacidade máxima de B tokens. Tokens são adicionados à taxa r por segundo. Cada requisição consome 1 token. Se o balde está vazio, a requisição é rejeitada (ou aguarda). Permite bursts até a capacidade do balde — cliente pode usar acumulado de tokens em um pico.

# Token Bucket — pseudocódigo
def check_rate_limit(consumer_id, capacity=100, refill_rate=10):
    now = time.now()
    bucket = redis.get(f"bucket:{consumer_id}") or {tokens: capacity, last_refill: now}

    # Refill tokens baseado no tempo decorrido
    elapsed = now - bucket.last_refill
    new_tokens = min(capacity, bucket.tokens + elapsed * refill_rate)

    if new_tokens < 1:
        return False, 429  # balde vazio

    redis.set(f"bucket:{consumer_id}", {tokens: new_tokens - 1, last_refill: now})
    return True, None

Leaky Bucket

Requisições entram no balde a qualquer taxa, mas saem (são processadas) a uma taxa constante. Excess é rejeitado ou enfileirado. Garante taxa constante de processamento — útil para suavizar bursts antes de chegar ao backend. Menos comum em API Gateways modernos; mais usado em traffic shaping de rede.

Granularidade de rate limiting

O gateway deve suportar múltiplos eixos de limitação simultaneamente:

• Por IP: proteção básica contra clientes anônimos e ataques
• Por consumer (API Key / usuário): garantia de uso justo entre clientes autenticados
• Por rota: endpoints mais caros (relatórios, batch) têm limites menores
• Por plano: tier free tem 100 req/dia; tier pro tem 100k req/dia
• Por janela: por segundo (burst), por minuto, por hora, por dia, por mês

# Kong — plugin rate-limiting avançado
plugins:
- name: rate-limiting-advanced
  config:
    limit_by: consumer          # limitar por consumer autenticado
    strategy: sliding-window
    limits:
      second: 20                # burst: 20 req/s
      minute: 500               # 500 req/min
      hour: 5000                # 5000 req/h
      day: 10000                # 10000 req/dia
    sync_rate: 10               # sincronizar contadores com Redis a cada 10s
    redis:
      host: redis.internal
      port: 6379
    error_message: "Rate limit excedido. Tente novamente após {reset_at}."
    hide_client_headers: false  # retornar X-RateLimit-* headers ao cliente

Headers de rate limiting

# Headers de resposta padronizados (IETF draft-ietf-httpapi-ratelimit-headers)
X-RateLimit-Limit: 1000          # limite total na janela atual
X-RateLimit-Remaining: 847       # requisições restantes
X-RateLimit-Reset: 1715285400   # Unix timestamp do reset
Retry-After: 60                  # segundos para aguardar (apenas quando 429)

# Quando limite é excedido:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1715285400

{
  "error": "rate_limit_exceeded",
  "message": "Limite de 1000 requisições por hora excedido",
  "retry_after_seconds": 60
}

Transformação de Payload

O gateway pode modificar requisições e respostas em trânsito — adicionando, removendo ou transformando campos, convertendo formatos, e adaptando contratos entre o que o cliente espera e o que o backend oferece.

Transformações comuns

# Kong — plugin request-transformer
plugins:
- name: request-transformer
  config:
    # Adicionar headers antes de encaminhar ao backend
    add:
      headers:
      - "X-Consumer-ID:$(consumer.id)"
      - "X-Request-ID:$(uuid)"
    # Remover headers sensíveis do cliente
    remove:
      headers:
      - "Authorization"   # backend não precisa do token JWT
      - "Cookie"

# Kong — plugin response-transformer
- name: response-transformer
  config:
    remove:
      json:
      - "internal_id"        # não expor ID interno do banco
      - "created_by_user_id" # não expor dado interno
    add:
      headers:
      - "X-API-Version:v1"

# Transformação de formato (REST → SOAP, JSON → XML)
# Geralmente requer scripting Lua (Kong) ou policies (APIM, Apigee)

Protocol translation — REST para gRPC

Um gateway moderno pode expor uma API REST externamente e traduzir para gRPC internamente — chamado de transcoding. O Envoy suporta isso nativamente com anotações google.api.http no .proto. O AWS API Gateway e o Azure APIM têm suporte limitado; Kong requer plugin customizado.

# Envoy como gateway com gRPC transcoding
# O cliente chama REST, o Envoy chama gRPC no backend

# envoy.yaml
http_filters:
- name: envoy.filters.http.grpc_json_transcoder
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder
    proto_descriptor: "/etc/envoy/api_descriptor.pb"  # arquivo binário do proto
    services:
    - "orders.v1.OrderService"
    print_options:
      add_whitespace: false
      always_print_primitive_fields: true

# Com isso:
# POST /v1/orders → gRPC OrderService.CreateOrder
# GET /v1/orders/{id} → gRPC OrderService.GetOrder
# (mapeamento via anotações google.api.http no .proto)

Request/Response validation

O gateway pode validar payloads contra um schema OpenAPI antes de encaminhar ao backend — rejeitando requisições malformadas com 400 antes de consumir recursos do serviço. Reduz carga nos backends e centraliza validação básica de formato.

# Kong — plugin request-validator
plugins:
- name: request-validator
  config:
    body_schema: |
      {
        "type": "object",
        "required": ["customer_id", "items"],
        "properties": {
          "customer_id": { "type": "string", "format": "uuid" },
          "items": {
            "type": "array",
            "minItems": 1,
            "items": {
              "type": "object",
              "required": ["product_id", "quantity"],
              "properties": {
                "product_id": { "type": "string" },
                "quantity": { "type": "integer", "minimum": 1 }
              }
            }
          }
        }
      }
    allowed_content_types:
      application/json: true
    version: draft4

Agregação de Backends

Em vez de o cliente fazer múltiplas requisições paralelas para diferentes serviços, o gateway pode agregar em uma única chamada — reduzindo latência total (especialmente crítico em redes móveis) e simplificando o cliente.

Parallel fan-out

# Cliente faz 1 request, gateway faz 3 em paralelo e combina
GET /api/dashboard → Gateway:
  paralelo:
    GET orders-service/api/recent-orders?user=123     → { orders: [...] }
    GET recommendations-service/api/for-user?id=123  → { products: [...] }
    GET notifications-service/api/unread?user=123     → { count: 5 }
  combina:
  → {
      recent_orders: [...],
      recommendations: [...],
      unread_notifications: 5
    }

# Latência total = max(latências individuais), não soma
# Sem agregação: 80ms + 120ms + 60ms = 260ms
# Com agregação: max(80, 120, 60) = 120ms

Implementação de agregação

Gateways de mercado (Kong Enterprise, Apigee) suportam aggregation via scripts Lua ou JavaScript. Alternativas mais limpas:

• GraphQL como BFF: o cliente especifica exatamente o que precisa e o servidor (BFF GraphQL) agrega internamente via DataLoaders
• BFF dedicado em código: um microserviço pequeno implementado na linguagem do time, que agrega chamadas internas e expõe o endpoint combinado
• AWS Step Functions / Azure Logic Apps: orquestração gerenciada para fluxos mais complexos

Circuit Breaker e Retry no Gateway

O gateway pode implementar circuit breaker para proteger clientes quando backends estão degradados — em vez de deixar requisições pendentes por 30 segundos antes de timeout, o gateway responde rapidamente com 503 quando o backend está com falha.

# Envoy — circuit breaker por cluster
clusters:
- name: orders_cluster
  circuit_breakers:
    thresholds:
    - priority: DEFAULT
      max_connections: 100          # máx. conexões simultâneas
      max_pending_requests: 50      # máx. requisições na fila
      max_requests: 200             # máx. requisições simultâneas
      max_retries: 3                # máx. retries simultâneos
      # quando limites são excedidos, Envoy retorna 503 imediatamente

# Envoy — outlier detection (passive circuit breaker)
  outlier_detection:
    consecutive_5xx: 5             # 5 erros 5xx consecutivos → ejetar instância
    interval: 10s
    base_ejection_time: 30s        # tempo mínimo fora do pool
    max_ejection_percent: 50       # no máximo 50% do pool pode ser ejetado

# Retry policy
  retry_policy:
    retry_on: "5xx,reset,connect-failure,retriable-4xx"
    num_retries: 2
    per_try_timeout: 5s
    retry_host_predicate:
    - name: envoy.retry_host_predicates.previous_hosts  # evitar host que já falhou

Retry only quando seguro

O gateway só deve fazer retry em operações idempotentes ou quando tem certeza de que o backend não processou a requisição (ex: falha de conexão antes de enviar). Retry cego em POST pode duplicar criações. Configure retry apenas para: GET/HEAD/OPTIONS (sempre idempotentes), conexões que falharam antes de chegar ao backend, e erros 503 com header Retry-After.

Portal do Desenvolvedor

Um API Gateway completo inclui um portal onde desenvolvedores externos podem descobrir APIs, gerar credenciais, testar endpoints em sandbox, e acompanhar uso e quotas. É a camada de produto da API — sem ela, uma API pública é apenas uma URL sem documentação.

Componentes de um portal maduro

• Catálogo de APIs: lista todas as APIs disponíveis com documentação interativa (OpenAPI/Swagger UI), exemplos de código gerados automaticamente, changelog e deprecations
• Self-service de credenciais: desenvolvedores criam aplicações e geram API Keys sem interação humana; o gateway cria o consumer e aplica o plano automaticamente
• Sandbox/Mock environment: ambiente isolado para testar sem impacto em produção; respostas simuladas para backends que ainda não existem
• Dashboard de uso: gráficos de requisições, erros, latência por endpoint e período; alertas quando quota está próxima do limite
• Planos e upgrade: fluxo de upgrade de plano com integração de billing (Stripe, etc.)
• Webhooks e notificações: alertas de rate limit, deprecation iminente, incidentes

Gestão do ciclo de vida da API

# Versionamento no gateway — múltiplas versões coexistindo
routes:
- name: orders-v1
  paths: ["/api/v1/orders"]
  service: orders-service-v1
  plugins:
  - name: response-transformer
    config:
      add.headers: ["Sunset: Sat, 31 Dec 2026 00:00:00 GMT",
                    "Deprecation: true",
                    "Link: </api/v2/orders>; rel=\"successor-version\""]

- name: orders-v2
  paths: ["/api/v2/orders"]
  service: orders-service-v2

# Quando v1 é deprecada:
# 1. Adicionar header Sunset com data de desativação
# 2. Logar consumidores ainda usando v1
# 3. Contactar consumidores com uso significativo
# 4. Desativar v1 na data de sunset

Soluções de Mercado

Kong Gateway (open source + enterprise)

Construído sobre nginx+OpenResty (Lua), é o API Gateway open source mais usado. A versão gratuita inclui roteamento, rate limiting, autenticação básica, plugins da comunidade. A versão Enterprise adiciona portal do desenvolvedor, RBAC granular, analytics avançado e suporte comercial. Configurável via Admin API REST, Deck (declarativo como código) ou KIC (Kubernetes Ingress Controller).

# Kong declarativo com Deck (deck.yaml)
services:
- name: orders-service
  url: http://orders-service:8080
  routes:
  - name: orders-route
    paths: ["/api/v1/orders"]
    methods: [GET, POST, PATCH, DELETE]
    strip_path: false
  plugins:
  - name: jwt
    config:
      secret_is_base64: false
      claims_to_verify: [exp, nbf]
  - name: rate-limiting
    config:
      minute: 1000
      hour: 10000
      policy: redis
      redis_host: redis.internal
  - name: correlation-id
    config:
      header_name: X-Request-ID
      generator: uuid#counter
  - name: prometheus  # métricas para Grafana/Prometheus
    config:
      per_consumer: true

AWS API Gateway

Serviço gerenciado da AWS — sem infraestrutura para operar. Dois tipos: REST API (mais completo, mais caro) e HTTP API (mais simples, mais barato, menor latência). Integra nativamente com Lambda, ECS, EKS, Cognito, WAF e CloudWatch. Rate limiting e throttling configurados via usage plans.

# AWS API Gateway via CDK (TypeScript)
const api = new RestApi(this, 'OrdersApi', {
  restApiName: 'Orders Service',
  defaultCorsPreflightOptions: {
    allowOrigins: Cors.ALL_ORIGINS,
    allowMethods: ['GET', 'POST', 'PATCH'],
  },
});

// Authorizer JWT com Cognito
const authorizer = new CognitoUserPoolsAuthorizer(this, 'Authorizer', {
  cognitoUserPools: [userPool],
});

// Rota com authorizer e integração Lambda
const orders = api.root.addResource('orders');
orders.addMethod('POST', new LambdaIntegration(createOrderFn), {
  authorizer,
  authorizationType: AuthorizationType.COGNITO,
});

// Usage plan — rate limiting e quotas
const plan = api.addUsagePlan('BasicPlan', {
  throttle: { rateLimit: 100, burstLimit: 200 },
  quota: { limit: 10000, period: Period.DAY },
});
plan.addApiStage({ stage: api.deploymentStage });

// API Key para acesso
const key = api.addApiKey('PartnerKey');
plan.addApiKey(key);

Azure API Management (APIM)

Solução enterprise da Microsoft com portal do desenvolvedor completo, políticas XML expressivas, integração com Azure AD e RBAC, suporte a mocking, e analytics nativo. Curva de aprendizado maior que Kong, mas integração excepcional com o ecossistema Azure.

<!-- Azure APIM — policies XML -->
<policies>
  <inbound>
    <!-- Validar JWT do Azure AD -->
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
      <openid-config url="https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration"/>
      <audiences><audience>api://orders-api</audience></audiences>
      <required-claims>
        <claim name="roles" match="any">
          <value>Orders.Read</value>
          <value>Orders.Write</value>
        </claim>
      </required-claims>
    </validate-jwt>

    <!-- Rate limiting por subscription key -->
    <rate-limit-by-key calls="100" renewal-period="60"
      counter-key="@(context.Subscription.Id)" />

    <!-- Injetar correlation ID -->
    <set-header name="X-Request-ID" exists-action="skip">
      <value>@(Guid.NewGuid().ToString())</value>
    </set-header>
  </inbound>

  <backend>
    <retry condition="@(context.Response.StatusCode == 503)" count="2" interval="1">
      <forward-request timeout="30" />
    </retry>
  </backend>

  <outbound>
    <!-- Remover headers internos da resposta -->
    <set-header name="X-Internal-Server" exists-action="delete"/>
    <!-- Adicionar rate limit headers -->
    <set-header name="X-RateLimit-Remaining">
      <value>@(context.Response.Headers.GetValueOrDefault("X-RateLimit-Remaining","")</value>
    </set-header>
  </outbound>
</policies>

Comparativo de soluções

API Gateway vs Service Mesh

Uma confusão comum: API Gateway e Service Mesh parecem resolver problemas similares (observabilidade, autenticação, retry), mas operam em camadas e escopos diferentes.

Em arquiteturas maduras, ambos coexistem: o API Gateway gerencia a entrada do tráfego externo, e o service mesh gerencia a comunicação interna entre serviços. O próximo conceito explora service meshes em profundidade.

Decisões de engenharia

Exercícios práticos

1. Instale o Kong localmente via Docker e configure um serviço para o seu backend local. Adicione os plugins: jwt (validação de token), rate-limiting (100 req/min por consumer), correlation-id e prometheus. Use deck dump para exportar a configuração declarativa. Critério: curl sem token retorna 401 com {"message": "Unauthorized"}; request com token válido passa; a 101ª request no minuto retorna 429 com Retry-After header; deck sync restaura a configuração completa a partir do YAML sem erros.
2. Implemente um BFF de agregação que combine dados de dois backends em uma única resposta, com tratamento de falha parcial: se um backend retornar 5xx, retorne os dados do que funcionou com partial: true. Critério: com ambos os backends funcionando, latência total ≤ max(latências individuais) + 10ms e partial: false; ao derrubar um backend, resposta em ≤ timeout_configurado com partial: true e dados do backend funcional; ambos os backends com 5xx retorna partial: true com listas vazias (não 500).
3. Implemente os quatro algoritmos de rate limiting (fixed window, sliding window counter, token bucket, leaky bucket) em memória. Teste o boundary: envie 100 requests nos últimos 500ms de uma janela e 100 nos primeiros 500ms da próxima. Critério: fixed window permite burst de 200 na fronteira; sliding window bloqueia o burst após ~100 requests em qualquer janela de 1 minuto; token bucket permite burst até o capacity configurado antes de restringir; leaky bucket processa a taxa constante independente do padrão de chegada.
4. Configure AWS API Gateway (ou Azure APIM) com duas usage plans: basic (100 req/min, 1k req/dia) e pro (1000 req/min, 100k req/dia). Crie uma API Key para cada plano. Critério: a key basic recebe 429 após 100 requests em 1 minuto enquanto a key pro continua funcionando; ambas recebem 429 após esgotarem a quota diária; headers X-RateLimit-Remaining são retornados em cada resposta com valor decrementando.
5. Implemente versionamento de API no gateway: exponha /api/v1/orders (backend legado) e /api/v2/orders (backend novo) simultaneamente. Critério: todas as respostas de /api/v1/orders incluem headers Sunset: <data-futura> e Deprecation: true; logs estruturados em JSON incluem campos consumer_id e api_version em cada request, permitindo query de "consumers ainda em v1"; /api/v2/orders responde sem headers Sunset.

Perguntas de entrevista