Questão de Sistemas Operacionais — Geral — VUNESP 2023

API Gateway: o ponto único de entrada para seus serviços

Gabarito: letra B. Um API gateway é, por definição, um componente posicionado entre o cliente (solicitante) e os serviços de back-end, atuando como um ponto único de entrada que recebe, roteia e orquestra as requisições. Ele não é um serviço de back-end em si, nem é restrito a uma linguagem ou sistema operacional específico — e é justamente essa posição intermediária que a alternativa B descreve com precisão.

O API gateway é uma peça central em arquiteturas de microsserviços e em APIs modernas. Pense nele como um porteiro de um prédio de escritórios: todos os visitantes (requisições) chegam primeiro ao porteiro, que verifica a identidade (autenticação), consulta a lista de permissões (autorização), anota a visita (logging) e então direciona cada pessoa ao escritório correto (roteamento). Sem o porteiro, cada visitante teria que saber exatamente em qual andar e sala cada empresa fica — o que seria caótico e inseguro. Da mesma forma, sem um API gateway, cada cliente precisaria conhecer e acessar diretamente cada serviço de back-end, o que expõe a arquitetura interna, dificulta o gerenciamento centralizado de segurança e torna o sistema mais frágil.

As principais responsabilidades de um API gateway incluem:

• Roteamento: encaminhar a requisição para o serviço de back-end correto, com base na URL, no método HTTP ou em outros critérios.

• Autenticação e autorização: validar credenciais (tokens JWT, OAuth, etc.) e verificar se o usuário tem permissão para acessar o recurso solicitado.

• Agregação: combinar respostas de múltiplos serviços em uma única resposta para o cliente, reduzindo o número de chamadas necessárias.

• Tradução de protocolos: converter protocolos, por exemplo, de HTTP para WebSocket ou para protocolos internos de comunicação.

• Rate limiting e quotas: controlar o número de requisições que um cliente pode fazer em um período, protegendo os serviços de sobrecarga.

• Logging e monitoramento: registrar todas as requisições e respostas, permitindo auditoria e análise de desempenho.

• Cache: armazenar respostas de requisições frequentes para reduzir a carga nos serviços de back-end.

É importante distinguir o API gateway de outros componentes de arquitetura:

A pegadinha desta questão é justamente a tentativa de associar o API gateway a tecnologias específicas (Java, Windows Server) ou a um papel que ele não desempenha (serviço de back-end). O candidato que conhece o conceito de forma sólida identifica rapidamente que a alternativa B é a única que descreve a posição arquitetural correta.

Guarde a essência: API gateway = intermediário. Ele fica entre o cliente e os serviços, nunca é o serviço em si, e é agnóstico de linguagem e plataforma. É com esse critério que vamos analisar cada alternativa.

Alternativa A — ❌ Incorreta

Afirma que o API gateway é um serviço de back-end que responde diretamente às requisições. Isso é um erro conceitual: o gateway não implementa a lógica de negócio — ele apenas encaminha as requisições para os serviços que a implementam. Se o gateway respondesse diretamente, ele seria o próprio serviço, e não um gateway. A função dele é ser um procurador (proxy) entre o cliente e o back-end, não o destinatário final.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a definição clássica: o API gateway é posicionado entre o solicitante das requisições e o(s) serviço(s) de back-end. Ele atua como um ponto único de entrada (single entry point), recebendo todas as requisições dos clientes e as roteando para os serviços apropriados. Essa posição intermediária é o que permite centralizar autenticação, rate limiting, logging e outras preocupações transversais, sem que cada serviço precise implementá-las individualmente.

Alternativa C — ❌ Incorreta

Diz que o API gateway é inadequado para prover autenticação. Na verdade, autenticação é uma das funções mais comuns e importantes de um API gateway. Ele valida tokens, chaves de API, certificados e outros mecanismos de autenticação antes de encaminhar a requisição ao back-end. Isso centraliza a segurança e evita que cada serviço precise implementar sua própria lógica de autenticação. A alternativa inverte completamente o papel do gateway.

Alternativa D — ❌ Incorreta

Afirma que o API gateway é uma tecnologia específica da linguagem Java. Isso é falso: existem API gateways implementados em diversas linguagens (Go, Node.js, Python, Java, etc.) e muitos são agnósticos de linguagem, funcionando como proxies independentes. Exemplos como Kong (Lua/OpenResty), NGINX (C) e AWS API Gateway (serviço gerenciado) demonstram que não há vínculo com Java. A alternativa tenta limitar o conceito a uma tecnologia, o que é um erro de generalização.

Alternativa E — ❌ Incorreta

Diz que o API gateway é uma tecnologia específica de servidores Windows Server, não disponível em Linux. Isso é duplamente errado: (1) a maioria dos API gateways é multiplataforma e roda perfeitamente em Linux (que é o ambiente mais comum para servidores); (2) existem gateways nativos de nuvem (AWS, Azure, GCP) que são independentes do sistema operacional subjacente. A alternativa tenta amarrar o conceito a uma plataforma específica, o que não procede.

Gabarito: letra B