HTTP: métodos seguros, idempotentes e códigos de status

HTTP é o protocolo da camada de aplicação que move a web, e as provas de Informática cobram dele três coisas: a diferença entre HTTP e HTTPS, o significado dos métodos (GET, POST, PUT, DELETE) e os códigos de status (404, 403, 500). Quase sempre a questão troca um código por outro ou confunde “seguro” com “idempotente”. Este guia usa como fonte a especificação da semântica do HTTP, o RFC 9110, do IETF, lida em texto integral. Para matéria técnica não há lei: a referência é a documentação aberta.

O básico: requisição e resposta

O cliente (navegador) envia uma requisição com um método e um endereço; o servidor devolve uma resposta com um código de status de três dígitos e, em geral, conteúdo. O esquema “http” usa por padrão a porta TCP 80, e o esquema “https” usa por padrão a porta TCP 443, segundo o RFC. HTTPS é o HTTP sobre conexão protegida por TLS; o método e os códigos são os mesmos, o que muda é o canal. Para o modelo de camadas, veja OSI e TCP/IP.

Os métodos principais

Método	Para que serve (resumo da especificação)
GET	Pedir a representação atual do recurso
HEAD	Igual ao GET, mas sem o conteúdo na resposta
POST	Pedir que o recurso de destino processe o conteúdo enviado, segundo a semântica do próprio recurso (por exemplo, enviar um formulário)
PUT	Substituir o estado do recurso pelo conteúdo enviado
DELETE	Remover a associação entre o recurso e sua funcionalidade
OPTIONS	Descobrir as opções de comunicação disponíveis para o recurso

O método PATCH, muito usado em APIs, não faz parte do RFC 9110; vem de outra especificação.

Método seguro x idempotente

Os dois conceitos são diferentes e a banca gosta de embaralhá-los.

Seguro: o método tem semântica essencialmente de leitura; o cliente não pede nem espera mudança de estado no servidor. Pela especificação, GET, HEAD, OPTIONS e TRACE são seguros.
Idempotente: repetir a mesma requisição várias vezes tem o mesmo efeito pretendido que enviá-la uma vez. Pela especificação, PUT, DELETE e todos os métodos seguros são idempotentes.

Consequência lógica, que rende questão: todo método seguro é idempotente, mas nem todo idempotente é seguro. O DELETE é idempotente (apagar duas vezes o mesmo recurso deixa o servidor no mesmo estado final), mas não é seguro (ele muda o estado). O POST não consta nem entre os seguros nem entre os idempotentes definidos no RFC.

Exemplo resolvido

Enunciado: “Um cliente reenviou, por falha de rede, a requisição PUT que substitui o cadastro de um item. Isso pode duplicar o cadastro?”

PUT é idempotente: o efeito de enviar duas vezes é o mesmo que enviar uma.
O segundo envio, portanto, apenas repete a substituição.
Com POST, que cria um recurso novo a cada processamento, o reenvio poderia criar dois registros.

A especificação observa que o cliente pode repetir automaticamente uma requisição idempotente, ao contrário de uma que não o seja; é por isso que formulários que usam POST pedem confirmação antes de reenviar.

Classes de status

O primeiro dígito do código define a classe:

Classe	Significado
1xx	Informativa
2xx	Sucesso
3xx	Redirecionamento
4xx	Erro do cliente
5xx	Erro do servidor

Códigos mais cobrados

Código	Nome	O que significa
200	OK	A requisição foi bem-sucedida
201	Created	A requisição resultou na criação de um ou mais recursos
204	No Content	Sucesso, sem conteúdo adicional na resposta
301	Moved Permanently	O recurso recebeu novo endereço permanente
302	Found	O recurso está temporariamente em outro endereço
307	Temporary Redirect	Redirecionamento temporário que não permite mudar o método
308	Permanent Redirect	Redirecionamento permanente que mantém o método
400	Bad Request	Requisição malformada ou inválida
401	Unauthorized	Faltam credenciais de autenticação válidas
403	Forbidden	O servidor entendeu, mas se recusa a atender
404	Not Found	O servidor não encontrou representação atual do recurso (ou não quer revelar que existe)
405	Method Not Allowed	Método reconhecido, mas não permitido para o recurso
500	Internal Server Error	Condição inesperada impediu o servidor de atender
502	Bad Gateway	Um gateway ou proxy recebeu resposta inválida do servidor a montante
503	Service Unavailable	Servidor incapaz de atender agora, por sobrecarga ou manutenção programada
504	Gateway Timeout	Um gateway ou proxy não recebeu resposta a tempo do servidor a montante

Pegadinhas de status

401 x 403. O 401 diz que faltam credenciais válidas (o servidor deve enviar o cabeçalho WWW-Authenticate). O 403 diz que o servidor entendeu o pedido e recusa, e repetir com as mesmas credenciais não adianta. Resumo: 401 é “identifique-se”; 403 é “sei quem você é (ou não importa) e a resposta é não”.
404 x 410. O 404 não indica se a ausência é temporária ou permanente; o 410 (Gone) é preferível quando o servidor sabe que é permanente. Além disso, um servidor pode usar 404 para esconder a existência de um recurso proibido.
302 x 307. Em um 302, por razões históricas o navegador pode trocar POST por GET no redirecionamento; no 307 isso é proibido.
500 x 502 x 503 x 504. O 500 é falha genérica do servidor. O 502 e o 504 aparecem quando há um intermediário (gateway ou proxy) e o problema está no servidor atrás dele. O 503 sugere condição temporária e pode vir com o cabeçalho Retry-After, que indica quanto esperar.

Erros comuns

Dizer que HTTPS usa outro conjunto de métodos. Os métodos e códigos são os mesmos.
Afirmar que DELETE é seguro.
Achar que “404” significa sempre que a página nunca existiu.
Confundir erro 4xx (culpa atribuída ao cliente) com 5xx (falha do servidor).
Tratar POST como idempotente.

Roteiro de estudo

Memorize as cinco classes.
Decore o quadro de códigos acima.
Treine os pares de confusão: 401 e 403; 301 e 302; 502, 503 e 504.
Classifique cada método como seguro, idempotente ou nenhum.

Próximos passos

Continue em redes e internet: conceitos e protocolos, veja DNS, DHCP e NAT e navegadores e correio eletrônico.

Fontes e atualização

Não há norma jurídica sobre o tema. Fonte técnica lida: o RFC 9110 (HTTP Semantics), do IETF, seções sobre métodos (9) e códigos de status (15); o texto está no site do IETF e do RFC Editor. Confira o edital e a bibliografia da banca; veja a metodologia do site.