HTTP e HTTPS no contexto de redes e desenvolvimento web
Toda aplicação web depende de uma troca contínua de mensagens entre cliente e servidor. Quando um sistema abre uma página, envia um formulário, consome uma API REST, carrega uma imagem ou autentica um usuário, há uma sequência de requisições e respostas trafegando pela rede. O protocolo HTTP, sigla para Hypertext Transfer Protocol, organiza essa comunicação na camada de aplicação, definindo métodos, cabeçalhos, códigos de status, mensagens de requisição e mensagens de resposta.
Na área de desenvolvimento web, compreender HTTP é importante posi ajuda a enxergar o sistema para além da interface. O programador deixa de ver apenas botões, formulários e telas e passa a entender como o navegador conversa com servidores, como uma API recebe dados, como o backend responde, como erros são comunicados e como a segurança da comunicação é estabelecida.Conforme Fielding, Nottingham e Reschke (2022), a especificação HTTP Semantics define que a semântica do HTTP envolve métodos, códigos de status, campos de cabeçalho, metadados e outros dados de controle usados nas mensagens.
O que é o protocolo HTTP?
HTTP é um protocolo de aplicação baseado no modelo requisição-resposta. Em termos simples, um cliente envia uma requisição para um servidor, e o servidor devolve uma resposta. O cliente pode ser um navegador, um aplicativo móvel, um script em JavaScript, uma ferramenta de linha de comando como curl ou outro servidor. O servidor pode ser uma aplicação Node.js, Java, PHP, Python, Go, C#, um gateway de API, um servidor de arquivos ou uma infraestrutura composta por balanceadores, caches e microsserviços.
A especificação moderna do HTTP separa a semântica do protocolo das versões de transporte. Isso significa que conceitos como método GET, código 200 OK, cabeçalho Content-Type e corpo JSON continuam tendo o mesmo sentido central em HTTP/1.1, HTTP/2 e HTTP/3, embora a forma de transportar as mensagens possa mudar (Fielding; Nottingham; Reschke, 2022). A documentação da MDN também destaca que HTTP/3 preserva a semântica central de métodos, status e cabeçalhos, mesmo mudando aspectos de transporte e enquadramento das mensagens (MDN, 2025).
Uma requisição HTTP possui, conceitualmente, método, alvo, versão do protocolo, cabeçalhos e, em alguns casos, corpo. Uma resposta HTTP possui versão, código de status, frase de status, cabeçalhos e, em muitos casos, corpo. Em APIs web modernas, é comum que o corpo das mensagens seja JSON, mas HTTP não se limita a JSON. Ele também transporta HTML, CSS, JavaScript, imagens, arquivos, XML, texto puro, áudio, vídeo e outros formatos.
O protocolo HTTP está, dentro do modelo TCP/IP de redes, na camada de aplicação. Ele depende de outras camadas para entregar os dados pela rede. Nas versões HTTP/1.1 e HTTP/2, a comunicação geralmente ocorre sobre TCP, enquanto em HTTP/3, ela ocorre sobre QUIC, que opera sobre UDP (Bishop, 2022).
Quando o usuário acessa o domínio https://exemplo.com/produtos, várias etapas ocorrem. Primeiro, o navegador precisa resolver o domínio por DNS, descobrindo o endereço IP do servidor. Depois, estabelece uma conexão de transporte. Em HTTPS (se for o caso), antes de enviar a requisição HTTP propriamente dita, ocorre uma negociação criptográfica por TLS. Somente após essa etapa a requisição HTTP é transmitida de forma protegida.
Ou seja, o HTTP não funciona isoladamente, pois são necessários diversos protocolos (DNS, IP, TCP ou QUIC, TLS), certificados digitais, portas e servidores. O programador web deve se atentar quanto a isso porque muitos erros de aplicação aparecem como sintomas de rede e não como falha de sistema propriamente. Por exemplo, um problema de DNS vai impedir que a requisição encontre o servidor; um bloqueio de porta vai impedir a conexão; um certificado inválido vai impedir a negociação por TLS e assim por diante.
Estrutura de uma requisição HTTP
Uma requisição HTTP pode ser compreendida por quatro partes principais: método, caminho do recurso, cabeçalhos e corpo. O método informa a intenção da operação, o caminho indica o recurso solicitado e os cabeçalhos transportam metadados. Por fim, o corpo, quando presente, transporta os dados enviados ao servidor.
Um exemplo conceitual de requisição seria:
GET /api/produtos?categoria=livros HTTP/1.1
Host: exemplo.com
Accept: application/json
User-Agent: Mozilla/5.0Essa requisição pede ao servidor o recurso /api/produtos, filtrando a categoria por meio da query string. O cabeçalho Accept: application/json indica que o cliente prefere receber uma resposta em JSON. O cabeçalho User-Agent descreve o agente cliente. Já o cabeçalho Host identifica o domínio de destino, algo essencial em servidores que hospedam múltiplos sites no mesmo endereço IP.
Uma requisição com corpo, comum em POST, poderia ser representada assim:
POST /api/produtos HTTP/1.1
Host: exemplo.com
Content-Type: application/json
Accept: application/json
{
"nome": "Teclado mecânico",
"preco": 250.00
}Nesse caso, o cabeçalho Content-Type: application/json informa que o corpo enviado está no formato JSON. A MDN descreve cabeçalhos HTTP como nomes insensíveis a maiúsculas e minúsculas, seguidos por dois-pontos e valor, como em Accept: application/json (MDN, 2025).
Estrutura de uma resposta HTTP
A resposta HTTP indica o resultado do processamento realizado pelo servidor. Ela contém um código de status, cabeçalhos e, frequentemente, um corpo. Um exemplo simplificado seria:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
{
"id": 1,
"nome": "Teclado mecânico",
"preco": 250.00
}O código 200 OK indica sucesso. O cabeçalho Content-Type informa o formato da resposta. O corpo contém os dados retornados. Em uma API REST, esse corpo costuma representar um recurso, uma lista de recursos, uma mensagem de erro ou o resultado de uma operação.
Os códigos de status são agrupados em classes. Em linhas gerais, podemos destacar os códigos assim:
1xxindicam informação;2xx, sucesso;3xx, redirecionamento;4xx, erro atribuído à requisição do cliente;5xx, erro no servidor.
A MDN observa que os códigos de status HTTP indicam se uma requisição foi concluída com sucesso e que os códigos listados são definidos pela RFC 9110 (MDN, 2026).
Métodos HTTP (GET, POST, PUT, PATCH e DELETE)
Os métodos HTTP comunicam a intenção da requisição. Em APIs web, eles são frequentemente associados a operações CRUD, mas essa associação deve ser entendida como uma convenção arquitetural apoiada pela semântica do protocolo, não como uma obrigação automática do banco de dados.
Para testar os métodos HTTP sem procisar de uma interface pronta, é possível usar o comando curl no terminal do sistemas operacional (cmd no Windows ou bash e equivalentes no Linux). O curl é uma ferramenta de linha de comando para transferir dados por URLs. Ele é muito útil porque remove a camada visual do navegador e permite testar a comunicação HTTP de forma direta. Segundo a documentação everything curl, ao realizar requisições HTTP, a biblioteca envia cabeçalhos adequados à tarefa solicitada, mas permite removê-los ou modificá-los quando necessário (Stenberg, 2026).
Também é possível verificar cabeçalhos via navegador, programas como Postman e Insomnia, scripts JavaScript ou Python… enfim, existem inúmeras formas de acessar esses dados. Você pode escolher conforme seu interesse, conhecimento e disponibilidade de ferramentas.
Método GET
O método GET solicita a representação de um recurso. Ele deve ser usado para leitura, como buscar uma lista de produtos ou obter os dados de um usuário. A documentação da MDN afirma que requisições GET devem apenas recuperar dados e não devem conter corpo com significado definido para alterar estado (MDN, 2025).
Exemplo de utilização do método GET com curl:
curl -i https://jsonplaceholder.typicode.com/posts/1O mesmo exemplo usando a linguagem JavaScript:
const resposta = await fetch("https://jsonplaceholder.typicode.com/posts/1", {
method: "GET",
headers: {
Accept: "application/json"
}
});
const postagem = await resposta.json();
console.log(postagem);Método POST
O método POST envia dados para processamento. Ele é comum na criação de recursos, submissão de formulários, autenticação e envio de comandos que podem gerar efeitos no servidor. A especificação HTTP permite que quase todos os códigos de status definidos possam aparecer em resposta a um POST, dependendo do resultado do processamento (Fielding; Nottingham; Reschke, 2022).
Exemplo de utilização com curl:
curl -i -X POST https://jsonplaceholder.typicode.com/posts \
-H "Content-Type: application/json" \
-d '{"titulo":"Aula de HTTP","corpo":"Estudando requisições","usuarioId":1}'Exemplo em JavaScript:
const novaPostagem = {
titulo: "Aula de HTTP",
corpo: "Estudando requisições",
usuarioId: 1
};
const resposta = await fetch("https://jsonplaceholder.typicode.com/posts", {
method: "POST",
headers: {
"Content-Type": "application/json",
Accept: "application/json"
},
body: JSON.stringify(novaPostagem)
});
const resultado = await resposta.json();
console.log(resultado);Método PUT
O método PUT substitui a representação atual de um recurso pelo conteúdo enviado na requisição. Em APIs REST, costuma ser usado para atualização completa. A MDN resume essa semântica ao afirmar que PUT substitui todas as representações atuais do recurso de destino pelo conteúdo da requisição (MDN, 2025).
Exemplo com curl:
curl -i -X PUT https://jsonplaceholder.typicode.com/posts/1 \
-H "Content-Type: application/json" \
-d '{"id":1,"titulo":"Título atualizado","corpo":"Conteúdo atualizado","usuarioId":1}'Exemplo em JavaScript:
const postagemAtualizada = {
id: 1,
titulo: "Título atualizado",
corpo: "Conteúdo atualizado",
usuarioId: 1
};
const resposta = await fetch("https://jsonplaceholder.typicode.com/posts/1", {
method: "PUT",
headers: {
"Content-Type": "application/json",
Accept: "application/json"
},
body: JSON.stringify(postagemAtualizada)
});
console.log(await resposta.json());Método PATCH
O método PATCH aplica modificações parciais em um recurso. Diferente de PUT, ele não exige enviar a representação completa. A RFC 5789 foi criada especificamente para definir o método PATCH no HTTP (Dusseault; Snell, 2010).
Exemplo com curl:
curl -i -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
-H "Content-Type: application/json" \
-d '{"titulo":"Somente o título foi alterado"}'Exemplo em JavaScript:
const alteracaoParcial = {
titulo: "Somente o título foi alterado"
};
const resposta = await fetch("https://jsonplaceholder.typicode.com/posts/1", {
method: "PATCH",
headers: {
"Content-Type": "application/json",
Accept: "application/json"
},
body: JSON.stringify(alteracaoParcial)
});
console.log(await resposta.json());Método DELETE
O método DELETE solicita a remoção de um recurso. Em uma API de produtos, por exemplo, DELETE /api/produtos/10 comunica a intenção de remover o produto identificado por 10. A MDN descreve DELETE como o método que exclui o recurso especificado (MDN, 2025).
Exemplo com curl:
curl -i -X DELETE https://jsonplaceholder.typicode.com/posts/1Exemplo em JavaScript:
const resposta = await fetch("https://jsonplaceholder.typicode.com/posts/1", {
method: "DELETE"
});
console.log(resposta.status);Métodos seguros, idempotentes e cacheáveis
Três propriedades ajudam a entender a escolha correta dos métodos HTTP: segurança, idempotência e cacheabilidade.
Um método seguro é aquele cuja intenção semântica é apenas leitura. GET é o exemplo clássico. Isso não significa que o servidor não possa registrar logs, métricas ou estatísticas de acesso, mas significa que o cliente não está solicitando alteração de estado do recurso. A RFC 9110 observa que a definição de métodos seguros não impede que uma implementação tenha comportamentos colaterais, desde que eles não sejam a ação solicitada pelo cliente (Fielding; Nottingham; Reschke, 2022).
Um método idempotente é aquele que pode ser repetido várias vezes com o mesmo efeito pretendido sobre o estado do servidor. PUT e DELETE são tratados como idempotentes em sua semântica. Enviar o mesmo PUT várias vezes tende a deixar o recurso no mesmo estado final. Enviar o mesmo DELETE várias vezes tende a manter o recurso removido, embora a primeira resposta possa ser 200 OK ou 204 No Content e as seguintes possam retornar 404 Not Found.
Finamente, a cacheabilidade indica se respostas podem ser armazenadas por navegadores, proxies ou caches intermediários. GET é o caso mais comum. POST também pode ser cacheável em condições explícitas, mas isso é menos frequente na prática. A MDN aponta que POST e PATCH podem ser cacheáveis quando a resposta inclui informações explícitas de frescor e um cabeçalho Content-Location correspondente (MDN, 2025).
Cabeçalhos HTTP essenciais para programação web
Como dissemos antes, cabeçalhos HTTP transportam metadados. Eles não são o conteúdo principal da aplicação, mas influenciam autenticação, cache, negociação de conteúdo, segurança, compressão, rastreamento, cookies e comportamento do navegador.
Com isso em mente, sabemos que o cabeçalho Content-Type informa o tipo de mídia do corpo. Em APIs JSON, costuma aparecer como application/json. O cabeçalho Accept informa o tipo de resposta esperado pelo cliente. O cabeçalho Authorization carrega credenciais, como tokens Bearer. O cabeçalho Cookie envia cookies do cliente para o servidor, enquanto Set-Cookie permite que o servidor solicite ao navegador o armazenamento de cookies.
Outros cabeçalhos são fundamentais para segurança e comportamento web. São eles:
Cache-Controldefine regras de cache.Locationaparece em redirecionamentos e na criação de recursos.OrigineAccess-Control-Allow-Originsão relevantes para CORS.User-Agentidentifica o cliente.Refererindica a página de origem em certos contextos.Strict-Transport-Securityinstrui o navegador a usar HTTPS em acessos futuros.
Com curl, é possível inspecionar cabeçalhos de resposta usando -I ou -i:
curl -I https://developer.mozilla.org/Códigos de status mais comuns
O código de status é a forma padronizada pela qual o servidor comunica o resultado de uma requisição. Para o programador web, saber ler esses códigos reduz o tempo de depuração dos sistemas.
Para a classe de códigos de sucesso, podemos citar:
- O código
200 OK, que indica sucesso com corpo de resposta. - O código
201 Created, que indica que um novo recurso foi criado, frequentemente após umPOST. - O código
204 No Content, que indica sucesso sem corpo de resposta, comum emDELETE.
Já na categoria de redirecionamento, os comuns são:
- Os códigos
301 Moved Permanentlye302 Found, indicando redirecionamentos. - O código
304 Not Modified, que informa que o recurso não mudou e pode ser reutilizado a partir do cache.
Entre os erros do cliente, temos:
400 Bad Requestindica requisição malformada;401 Unauthorizedindica ausência ou falha de autenticação;403 Forbiddenindica que o cliente foi compreendido, mas não tem autorização;404 Not Foundindica recurso não encontrado;409 Conflictindica conflito com o estado atual do recurso;422 Unprocessable Contenté comum em validações de APIs.
E do lado de erros do servidor:
500 Internal Server Errorindica falha genérica no backend;502 Bad Gatewayindica problema ao atuar como gateway ou proxy;503 Service Unavailableindica indisponibilidade temporária;504 Gateway Timeoutindica estouro de tempo ao aguardar outro serviço.
Uma dica: esses códigos devem ser escolhidos com cuidado. Uma API que retorna 200 OK para todos os casos de resposta dificulta a depuração, prejudica clientes automatizados e reduz a clareza semântica da aplicação. Por isso, leia atentamente a tabela de status code da MDN (clique aqui para abrir) para conhecer melhor todas as opções disponíveis.
O que é HTTPS?
O chamado HTTPS é, na verdade, o protocolo HTTP sobre uma camada criptográfica, normalmente TLS. O objetivo disso é proteger a comunicação contra leitura indevida, alteração de dados e falsificação do servidor. A letra “S” não muda a semântica principal do HTTP (um GET, um POST, um 404 ou um Content-Type continuam existindo), pois o que muda é o canal pelo qual essas mensagens trafegam.
Em HTTPS, o cliente verifica um certificado digital apresentado pelo servidor e esse certificado associa uma chave pública a um domínio, como exemplo.com. O navegador valida se o certificado foi emitido por uma autoridade certificadora confiável, se está dentro do prazo de validade e se corresponde ao domínio acessado. Quando a validação funciona, o navegador estabelece uma sessão criptografada e o usuário final verá a forma de um cadeado no navegador, indicando que a utilização do HTTPS.
Na prática, o HTTPS encapsula os dados HTTP dentro de uma camada criptográfica TLS, oferecendo confidencialidade, integridade e autenticação do servidor. A confidencialidade vai contribuir na proteção do conteúdo contra leitura por terceiros, ao mesmo tempo que a integridade dificultará alterações silenciosas durante o transporte. Além disso, com a autenticação do servidor, há redução no risco de o cliente se comunicar com um serviço impostor.
Essas propriedades não resolvem todos os problemas de segurança de uma aplicação, mas formam a base mínima para comunicação web moderna. Ainda assim, um sistema pode sofrer problemas de SQL Injection, XSS, autenticação fraca, autorização mal implementada, vazamento de tokens ou regras de negócio vulneráveis.
Inspecionando requisições no navegador
O navegador é uma ferramenta de análise HTTP. No Chrome, Edge, Firefox ou qualquer outro navegador, você pode abrir as ferramentas de desenvolvedor, acessar a aba “Network” ou “Rede” e recarregar a página. Cada linha exibida representa um recurso solicitado ao servidor durante a requisição, sendo elas: documento HTML, arquivos CSS, scripts JavaScript, imagens, fontes, chamadas fetch, requisições XHR e outros recursos.
Ao clicar em uma requisição, normalmente é possível observar a URL, o método, o código de status, os cabeçalhos de requisição, os cabeçalhos de resposta, os cookies, o corpo enviado, o corpo recebido, o tempo de espera e a ordem de carregamento.
Essa inspeção é importante para tentarmos responder perguntas objetivas como: o frontend realmente chamou a API? O método enviado foi POST ou GET? O corpo JSON foi enviado corretamente? O token de autenticação entrou no cabeçalho? A resposta veio com 401, 403, 404 ou 500? O servidor retornou Content-Type: application/json? Houve algum erro? O navegador bloqueou a requisição por política de segurança?
Exemplo de API básica com JavaScript
O código abaixo cria uma API simples com Node.js usando apenas recursos básicos do módulo HTTP. Em projetos reais, frameworks como Express, Fastify ou NestJS são comuns, mas este exemplo expõe melhor a estrutura das requisições e respostas.
import http from "node:http";
let produtos = [
{ id: 1, nome: "Mouse", preco: 80 },
{ id: 2, nome: "Teclado", preco: 150 }
];
function enviarJson(resposta, status, dados) {
resposta.writeHead(status, {
"Content-Type": "application/json; charset=utf-8"
});
resposta.end(JSON.stringify(dados));
}
async function lerCorpo(requisicao) {
const partes = [];
for await (const parte of requisicao) {
partes.push(parte);
}
const texto = Buffer.concat(partes).toString();
if (!texto) {
return null;
}
return JSON.parse(texto);
}
const servidor = http.createServer(async (requisicao, resposta) => {
const url = new URL(requisicao.url, "http://localhost:3000");
if (url.pathname === "/produtos" && requisicao.method === "GET") {
return enviarJson(resposta, 200, produtos);
}
if (url.pathname === "/produtos" && requisicao.method === "POST") {
const corpo = await lerCorpo(requisicao);
const novoProduto = {
id: produtos.at(-1)?.id + 1 || 1,
nome: corpo.nome,
preco: corpo.preco
};
produtos.push(novoProduto);
return enviarJson(resposta, 201, novoProduto);
}
const resultado = url.pathname.match(/^\/produtos\/(\d+)$/);
if (resultado) {
const id = Number(resultado[1]);
const indice = produtos.findIndex((produto) => produto.id === id);
if (indice === -1) {
return enviarJson(resposta, 404, {
erro: "Produto não encontrado"
});
}
if (requisicao.method === "GET") {
return enviarJson(resposta, 200, produtos[indice]);
}
if (requisicao.method === "PUT") {
const corpo = await lerCorpo(requisicao);
produtos[indice] = {
id,
nome: corpo.nome,
preco: corpo.preco
};
return enviarJson(resposta, 200, produtos[indice]);
}
if (requisicao.method === "PATCH") {
const corpo = await lerCorpo(requisicao);
produtos[indice] = {
...produtos[indice],
...corpo
};
return enviarJson(resposta, 200, produtos[indice]);
}
if (requisicao.method === "DELETE") {
produtos = produtos.filter((produto) => produto.id !== id);
resposta.writeHead(204);
return resposta.end();
}
}
return enviarJson(resposta, 404, {
erro: "Rota não encontrada"
});
});
servidor.listen(3000, () => {
console.log("Servidor HTTP em execução em http://localhost:3000");
});Esse exemplo de script permite praticar os métodos principais HTTP vistos anteriormente. Antes de continuar, um disclaimer rápido: recomendamos aplicar os comandos usando terminal Bash do Linux ou equivalentes. Caso prefira o CMD ou PowerShell do Windows, é possível que o curl dê problema nos métodos que envolvem a passagem de JSON. Aparentemente é alguma questão envolvendo a formatação das aspas que são enviadas junto com os dados por estes dois terminais Windows.
Agora, de volta os comandos do exemplo:
curl -i http://localhost:3000/produtoscurl -i -X POST http://localhost:3000/produtos \
-H "Content-Type: application/json" \
-d '{"nome":"Monitor","preco":900}'curl -i -X PUT http://localhost:3000/produtos/1 \
-H "Content-Type: application/json" \
-d '{"nome":"Mouse gamer","preco":120}'curl -i -X PATCH http://localhost:3000/produtos/1 \
-H "Content-Type: application/json" \
-d '{"preco":110}'curl -i -X DELETE http://localhost:3000/produtos/1Diagrama conceitual da arquitetura web
Para aquelas pessoas que entendem melhor os conceitos quando veem eles desenhados, a Figura 1 descreve o fluxo de uma arquitetura comum em aplicações web.
Fonte: Autoria própria.
Nesse fluxo, o HTTP estrutura a conversa entre cliente e servidor e o HTTPS protege essa conversa. A API, por sua vez, interpreta método, rota, cabeçalhos e corpo. Essa separação ajuda a compreender que uma falha pode ocorrer em pontos diferentes durante a tentativa de troca de dados (rede, TLS, servidor web, API, validação, autenticação, autorização ou persistência).
Conclusão
HTTP e HTTPS são fundamentos que ajudam a explicar como navegadores, APIs, servidores e clientes de linha de comando trocam informações pela rede. Além deles, as ideias de requisições, respostas, métodos, cabeçalhos e códigos de status permite diagnosticar erros com mais precisão, projetar APIs mais claras e compreender a infraestrutura que sustenta aplicações modernas.
Obrigado pela leitura e bons estudos!
Referências
BISHOP, Mike. RFC 9114: HTTP/3. [S. l.]: RFC Editor, 2022. Disponível em: https://www.rfc-editor.org/rfc/rfc9114.html. Acesso em: 12 ago. 2026.
DUSSEAULT, Lisa; SNELL, James M. RFC 5789: PATCH Method for HTTP. [S. l.]: RFC Editor, 2010. Disponível em: https://www.rfc-editor.org/info/rfc5789/. Acesso em: 12 ago. 2026.
FIELDING, Roy T.; NOTTINGHAM, Mark; RESCHKE, Julian. RFC 9110: HTTP Semantics. [S. l.]: IETF, 2022. Disponível em: https://datatracker.ietf.org/doc/html/rfc9110. Acesso em: 12 ago. 2026.
MDN WEB DOCS. HTTP request methods. [S. l.]: Mozilla, 2025. Disponível em: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods. Acesso em: 12 ago. 2026.
MDN WEB DOCS. HTTP response status codes. [S. l.]: Mozilla, 2026. Disponível em: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status. Acesso em: 12 ago. 2026.
STENBERG, Daniel. everything curl: requests. [S. l.]: Everything Curl, 2026. Disponível em: https://everything.curl.dev/libcurl-http/requests.html. Acesso em: 12 ago. 2026.
