Erros que cometi ao criar minha primeira API
Tempo de leitura: 6 minutos
Os primeiros passos de desenvolvimento backend são, sem sombra de dúvidas, a criação de APIs. Inicialmente, a preocupação de maior dificuldade que enfrentamos é entender os protocolos de comunicação, mas mais para frente, irei abordar com mais detalhes esses tópicos. Agora vamos nos concentrar nos principais erros que são comuns de acontecer quando estamos dando os primeiros passos.
Limitar a Quantidade de Requisições (Rate Limiting)
Um dos primeiros erros que cometi foi não me preocupar com a quantidade de requisições que minha API poderia receber. No início, tudo funciona bem em ambiente local ou com poucos usuários, então é fácil ignorar esse tipo de problema.
O problema aparece quando a aplicação começa a crescer. Sem nenhum tipo de limitação, um único usuário — ou até mesmo um script automatizado — pode sobrecarregar a API, causando lentidão ou até indisponibilidade.
Foi aí que entendi a importância de conceitos como rate limiting, throttling e controle de uso por cliente. Implementar essas estratégias desde cedo ajuda a proteger sua aplicação e garante um uso mais equilibrado dos recursos.
Hoje, existem diversas formas de implementar isso, seja via middlewares (como no Express), proxies reversos ou até API Gateways.
Protocolos de Comunicação
Outro ponto que subestimei no começo foi o entendimento dos protocolos de comunicação. Eu tratava APIs basicamente como um “envia e recebe”, sem me aprofundar no que realmente acontece por trás.
Com o tempo, percebi que entender bem o protocolo HTTP é essencial. Métodos como GET, POST, PUT e DELETE não são apenas convenções — eles carregam significado e impacto direto no design da API.
Além disso, conceitos como status codes, headers, cache, idempotência e segurança fazem toda a diferença na construção de uma API consistente e previsível.
Ignorar esses fundamentos pode levar a endpoints confusos, difíceis de manter e até problemáticos para quem consome a API.
Falta de conhecimento sobre outras abordagens (gRPC, GraphQL, etc.)
No começo, eu achava que REST era a única forma de construir APIs — e, por muito tempo, foi o suficiente. Mas, com o passar do tempo, percebi que existem outras abordagens que podem ser mais adequadas dependendo do contexto.
O gRPC, por exemplo, é extremamente eficiente para comunicação entre serviços, principalmente em ambientes de microserviços, graças ao uso de HTTP/2 e serialização binária.
Já o GraphQL traz uma proposta diferente: permitir que o cliente defina exatamente quais dados quer receber. Isso evita overfetching e underfetching, problemas comuns em APIs REST mal estruturadas.
Não conhecer essas alternativas limita sua capacidade de tomar boas decisões arquiteturais. Não significa que você precisa usar todas, mas entender quando cada uma faz sentido é um diferencial importante.
Falta de validação de dados (com Zod, por exemplo)
Outro erro clássico foi não validar corretamente os dados que chegavam na API. No começo, eu confiava que o frontend sempre enviaria tudo corretamente — o que, na prática, não acontece.
Isso pode gerar diversos problemas: dados inconsistentes, erros inesperados e até vulnerabilidades de segurança.
Foi então que comecei a utilizar bibliotecas de validação como o Zod. Com ele, é possível definir schemas claros e garantir que os dados recebidos estejam no formato esperado antes mesmo de chegar na lógica principal da aplicação.
Além de aumentar a segurança, isso também melhora muito a legibilidade e manutenção do código, deixando explícito o contrato da API.
Segurança: o erro de achar que “depois eu vejo isso”
Se tem um erro que eu cometi — e que vejo muita gente cometendo — foi tratar segurança como algo secundário. No início, a preocupação é fazer funcionar. Autenticar, persistir dados, retornar respostas… e só.
O problema é que APIs expostas na internet são alvos constantes, mesmo quando o projeto ainda é pequeno. Não existe “API pequena demais para ser atacada”.
Falta de autenticação e autorização adequadas
No começo, é comum implementar algo simples demais — ou pior, nem implementar. Muitas vezes, um token fixo, um segredo hardcoded ou até endpoints completamente abertos.
Com o tempo, fica claro que autenticação (quem é você?) e autorização (o que você pode fazer?) são coisas diferentes — e igualmente importantes.
Hoje, o mais comum é utilizar JWT, OAuth ou sessões bem estruturadas. Além disso, é essencial validar permissões em cada endpoint sensível.
Exposição de dados sensíveis
Outro erro clássico é retornar mais dados do que deveria. Às vezes, por conveniência, acabamos expondo informações sensíveis como:
- IDs internos desnecessários
- Emails ou dados pessoais
- Estruturas completas do banco
Isso pode parecer inofensivo no começo, mas é um prato cheio para exploração.
Uma boa prática é sempre controlar exatamente o que a API retorna, usando DTOs ou camadas de transformação.
Falta de validação e sanitização
Mesmo com validação de schema (como com Zod), ainda existe um ponto importante: sanitização.
Inputs do usuário nunca devem ser confiados. Sem esse cuidado, sua API pode ficar vulnerável a ataques como:
- SQL Injection
- NoSQL Injection
- XSS (em alguns contextos)
A validação garante formato. A sanitização garante segurança.
Não usar HTTPS
Pode parecer básico, mas vale reforçar: nunca exponha sua API sem HTTPS.
Sem criptografia, qualquer dado trafegado pode ser interceptado — incluindo tokens, senhas e informações sensíveis.
Hoje, com ferramentas como proxies, CDNs e serviços cloud, isso é praticamente obrigatório e fácil de configurar.
Falta de controle de erros e logs
No começo, eu retornava erros direto do backend — muitas vezes com stack trace completo. Isso ajuda no desenvolvimento, mas em produção é um risco enorme.
Mensagens de erro podem revelar detalhes da arquitetura, queries e até vulnerabilidades.
O ideal é:
- Retornar mensagens genéricas para o cliente
- Logar detalhes internamente (com cuidado)
- Evitar expor informações sensíveis nos logs
Segurança não é algo que você adiciona depois. É algo que precisa ser pensado desde o início.
Não precisa começar perfeito, mas ignorar completamente esse aspecto pode custar caro — seja em dados vazados, indisponibilidade ou perda de confiança.
Com o tempo, você percebe que uma API segura não é necessariamente mais complexa — ela só é mais bem pensada.
Esses foram alguns dos principais erros que cometi no início da minha jornada com APIs. Com o tempo, fui percebendo que construir uma API vai muito além de simplesmente fazer endpoints funcionarem — envolve pensar em escalabilidade, segurança, padrões e experiência para quem vai consumir.
E, como tudo em tecnologia, aprender com os erros faz parte do processo.
