O que é uma solicitação no contexto de desenvolvimento
A solicitação, ou request em inglês, é a mensagem que um cliente envia para um servidor pedindo alguma ação. Pode ser acessar uma página web, enviar um formulário, fazer login ou baixar dados. É a base de como todo o sistema da internet funciona.
Preciso entender antes de começar
Todo navegador faz solicitações o tempo todo. Quando você digita uma URL e aperta Enter, seu navegador envia uma solicitação HTTP GET para o servidor daquele domínio. O servidor responde com HTML, CSS, JavaScript e aí o browser renderiza a tela. Esse ciclo acontece milhares de vezes por carregamento de página. O que a maioria dos iniciantes não percebe é que existirem vários tipos de solicitação dentro do próprio HTTP. Não é só GET e POST. Tem também PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE e CONNECT. Cada um com semântica diferente e uso específico.
Como funciona na prática
Eu comecei a programar API em 2016 e meu primeiro erro foi tratar todas as requisições como se fossem iguais. Usei POST para tudo: buscar dados, criar registros, atualizar, deletar. Funcionava, mas criou uma dor de cabeça enorme depois quando precisei fazer caching, configurar filas de processamento e escalar o serviço. Um GET deveria buscar dados. Um POST criar recursos. Um PUT substituir um recurso completamente. Um PATCH fazer atualização parcial. Um DELETE remover. A diferença parece óbvia agora, mas na época eu não via vantagem em seguir esse padrão. Perdi semanas refatorando porque o frontend enviava PUT quando deveria enviar PATCH, e eu estava tratando como se fosse a mesma coisa.
O formato mais comum para payloads de dados é JSON. Antes do JSON dominar, muita gente usava XML. Ainda existe API que responde em XML por questões de legado, mas não há motivo técnico pra manter isso em projetos novos.
Componentes de uma solicitação HTTP
Uma requisição HTTP tem partes fixas que precisam existir:
- Método: GET, POST, PUT, PATCH, DELETE — define o que quer fazer.
- URL: o endereço completo, incluindo host, porta e path.
- Cabeçalhos (headers): metadados como Content-Type, Authorization, Accept, Cookie.
- Corpo (body): os dados enviados junto, presente principalmente em POST e PUT.
- Query params: parâmetros na URL depois do ponto de interrogação, usados para filtragem e paginação.
Um exemplo real seria algo assim:
POST https://api.exemplo.com/v2/produtos
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
{
"nome": "teclado mecânico",
"preco": 249.90,
"categoria": "perifericos",
"estoque": 150
}O servidor responde com um status code e um corpo. Status 200 é sucesso. 201 é recurso criado. 400 é erro do cliente. 401 é não autorizado. 404 é não encontrado. 429 é muitos pedidos, ou seja, você está sendo rate-limited. 500 é problema no servidor. Os códigos na faixa de 400 significam que o problema veio de quem enviou a requisição, não do servidor.
A armadilha do status 200 para erros
Isso é algo que eu vi em várias APIs no mercado: desenvolvedores usando status 200 mesmo quando algo dá errado dentro do corpo da resposta. Aí você precisa parsear o JSON, verificar se existe um campo "erro" ou "success", e ainda lidar com mensagens de erro que variam de API pra API. Isso é uma má prática conhecida. APIs bem desenhadas retornam status code apropriado no nível da resposta HTTP e um JSON estruturado no corpo com detalhes do erro. Se você estiver consumindo uma API que não faz isso, não adianta reclamar. Prepare o código para lidar com isso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Timeout e retry
Configure timeout. Padrão seguro é 5 a 10 segundos pra requisições HTTP comuns. Se a API que você consome for lenta, aumente. Mas nunca deixe sem timeout. Sem timeout, sua aplicação trava esperando uma resposta que nunca vai chegar, e isso acumula conexões e pode derrubar seu serviço. Reprise automática (retry) deve ser usada com cuidado. Só faça retry em requisições idempotentes, ou seja, GET e DELETE. Nunca faça retry em POST que cria dados, a menos que seu código trate duplicação. Eu já vi um sistema de pedidos criar o dobro de pedidos porque o desenvolvedor colocou retry em uma chamada POST sem proteger contra duplicidade.
Use backoff exponencial. Primeiro retry em 1 segundo, depois 2, depois 4. Nunca tente novamente no mesmo instante. E configure um limite máximo de retries, senão seu sistema fica preso num loop infinito.
Headers que todo mundo esquece mas importa
Content-Type: application/json diz ao servidor qual o formato do corpo. Se enviar errado, o servidor pode rejeitar ou interpretar mal os dados. Authorization: Bearer
User-Agent: identifique seu serviço. Ajuda no suporte técnico e às vezes é usado para aplicar políticas de rate limiting diferenciadas.
Erros comuns que vejo todo dia
CORS é o erro que mais gera confusão. O browser bloqueia requisições entre origens diferentes por segurança. A solução não é desabilitar CORS no frontend. A solução é configurar o servidor corretamente com os headers Access-Control-Allow-Origin, Access-Control-Allow-Methods e Access-Control-Allow-Headers. Se você está desenvolvendo localmente e o backend tá em outra porta, precisa configurar isso no backend, não no frontend. Eu já gastei duas horas caçando bug de CORS até perceber que o problema era configuração do servidor, não do código JavaScript. Encoding de URL também causa problemas. Acentos, espaços e caracteres especiais no path ou query precisam ser codificados. Use encodeURIComponent() no JavaScript, ou a função equivalente na linguagem que estiver usando. Esquecer disso gera erro 400 ou piores: dados corrompidos indo pro banco.
Testando sem depender do backend
Antes de integrar com a API real, teste com ferramentas como Postman, Insomnia ou curl. O curl é mais direto:
curl -X POST https://api.exemplo.com/v2/produtos \
-H "Content-Type: application/json" \
-H "Authorization: Bearer SEU_TOKEN" \
-d '{"nome": "mouse", "preco": 89.90}'Se a resposta vier correta no curl, o problema provavelmente tá no frontend. Se não vier, o problema é no backend ou na URL. Postman permite salvar coleções inteiras de requisições e testar em lote. Insomnia é uma alternativa mais leve. Ambas têm versão gratuita.
Quando usar WebSocket em vez de HTTP
Solicitações HTTP são stateless. Cada requisição é independente. Se você precisa de comunicação em tempo real, como chat, notificações ao vivo ou streaming de dados, HTTP tradicional não é eficiente. WebSocket mantém uma conexão aberta e permite envio de dados em ambas as direções sem overhead constante de headers. Se seu sistema precisa de atualização em tempo real, WebSocket é a escolha certa. Caso contrário, fique com HTTP. A maioria dos projetos não precisa de WebSocket, e muitos desenvolvedores adicionam essa complexidade desnecessariamente.
Resumo prático
Entender o que é solicitação significa entender o fluxo completo: cliente envia método mais URL mais headers mais corpo, servidor processa e responde com status code mais headers mais corpo. O resto é implementação. Erros acontecem quando algum desses componentes está errado ou faltando. Debugging é basicamente verificar cada parte separadamente. Aprender a ler status codes, configurar headers corretamente e lidar com timeouts economiza horas de frustração. A maior parte dos problemas que vejo em produção são falta de tratamento de erro, timeout mal configurado ou header ausente. Resolver esses três pontos já te coloca à frente da maioria.
