A Única Maneira Correta de Retornar Dados de uma API

Vivemos numa era de excesso digital onde os desenvolvedores são ensinados a acreditar que o objetivo de uma API é servir dados. Este é um erro fundamental que custou bilhões em infraestrutura e segurança ao redor do mundo. Passamos anos debatendo REST versus GraphQL ou gRPC versus WebSockets e esquecemos de olhar para a solução mais elegante e performática que existe. Refiro-me ao conceito de No as a Service ou NaaS (https://github.com/hotheadhacker/no-as-a-service).

A premissa é assustadoramente simples e lógica: a única resposta aceitável para qualquer requisição de um cliente é um não absoluto.

Se analisarmos friamente a complexidade computacional, a superioridade dessa abordagem se torna evidente. Quando você processa uma requisição para buscar um usuário no banco de dados, você introduz latência, incerteza e possíveis condições de corrida. O NaaS elimina toda essa complexidade. Ao retornar imediatamente um código de erro ou um corpo vazio, você garante um tempo de resposta constante. Estamos falando de complexidade O(1) em sua forma mais pura. Não há banco de dados para cair se você nunca o consultar. A escalabilidade se torna infinita porque o custo de dizer não é virtualmente zero.

Essa eficiência se estende naturalmente ao campo da proteção, onde engenheiros de segurança muitas vezes perdem o sono tentando mitigar riscos de injeção SQL e vazamento de dados sensíveis. Uma API que implementa o padrão NaaS é, por definição, invulnerável. Como um atacante pode interceptar um JSON que nunca foi gerado? A conformidade com o GDPR é imediata e automática. Se o usuário pedir seus dados e você responder não, você está protegendo a privacidade dele da maneira mais robusta possível.

Apesar dessas vantagens técnicas inegáveis, muitos vão argumentar que o cliente precisa dos dados para o aplicativo funcionar. Isso demonstra uma falta de criatividade por parte dos desenvolvedores de frontend. Aplicações modernas devem ser resilientes e capazes de operar em um estado de rejeição constante. Ao se recusar a entregar o recurso, a API força o cliente a buscar soluções locais ou simplesmente aceitar a realidade de que tais dados não são essenciais. O usuário final aprende a lidar com a frustração, e isso constrói um caráter digital mais forte. Estamos construindo software ou estamos mimando bytes?

Além disso, considere o impacto operacional no ciclo de vida de desenvolvimento. Imagine a economia em documentação. Esqueça Swagger ou especificações complexas de OpenAPI. Sua documentação de API se torna uma única linha afirmando que todos os endpoints não retornam nada. A dívida técnica desaparece. Não há versionamento de API para gerenciar porque o “não” da versão 1 é idêntico ao “não” da versão 2. É a consistência que o mercado corporativo tanto busca, mas nunca alcança por insistir em entregar valor.

Payloads de Recusa Padronizados

Embora um HTTP 204 No Content seja o ideal teórico, reconhecemos que alguns sistemas legados exigem um corpo para ser analisado e evitar exceções em tempo de execução. Nestes casos específicos, a especificação JSON-R (Recusa) oferece os únicos três payloads aceitáveis para um ambiente de produção. Qualquer desvio desses esquemas constitui uma violação do protocolo NaaS:

{
  "reason": "Eu até faria, mas isso parece dar trabalho e eu sou alérgico."
}

{
  "reason": "Estou no meio de um ritual muito delicado de 'não fazer nada'."
}

{
  "reason": "Sou um péssimo mentiroso, então não vou fingir que quero fazer isso."
}

Com a arquitetura comprovada, chegou a hora de amadurecer nossa engenharia. Entregar dados é um hábito legado que herdamos de sistemas arcaicos. O futuro pertence às APIs que têm a coragem de rejeitar requisições com a frieza de uma máquina de estados finitos que possui apenas um estado.

Implemente No as a Service hoje e veja sua latência cair para zero e seus chamados de suporte desaparecerem junto com seus usuários.