Quais são as principais diferenças entre os métodos de requisição HTTP GET e POST?

Finalidade

• GET solicita uma representação de um recurso. Pela especificação, ele é somente leitura: o cliente não espera nenhuma alteração no estado do servidor. A RFC 9110 observa que enviar um corpo em uma requisição GET tem semântica indefinida, portanto o GET não deve carregar um corpo.
• POST solicita que o recurso de destino processe os dados incluídos no corpo da requisição de acordo com a semântica desse próprio recurso (criar um registro, enviar um formulário, carregar um arquivo etc.).

Onde os dados vão

• GET carrega parâmetros na string de consulta da URL (após ?, formatada como key=value&...). Eles ficam visíveis na barra de endereços e são registrados no histórico do navegador e nos logs do servidor, além de estarem sujeitos a um limite prático de comprimento da URL.
• POST carrega dados no corpo da requisição; o tipo é informado pelo cabeçalho Content-Type. Formulários HTML normalmente usam application/x-www-form-urlencoded (o padrão) ou multipart/form-data (para arquivos). Não há um limite fixo no nível do protocolo, mas servidores e proxies configuram seus próprios máximos (por exemplo, Nginx client_max_body_size).

Propriedades segundo a RFC 9110

• Seguro: GET é seguro (somente leitura); POST não é.
• Idempotente: uma requisição é idempotente se executá-la N vezes tiver o mesmo efeito no estado do servidor que executá-la uma vez. GET é idempotente; POST não é — repeti-lo pode criar duplicatas, como dois pedidos idênticos. Idempotente não é o mesmo que seguro (PUT e DELETE são idempotentes, mas não seguros), e isso não diz nada sobre o corpo da resposta ser idêntico.
• Cacheável: respostas GET são cacheáveis por padrão; respostas POST só são cacheáveis quando incluem informações explícitas de frescor e um cabeçalho Content-Location correspondente, o que é raro na prática.

Implicações práticas

• Use GET para recuperação e navegação; os resultados podem ser repetidos com segurança, salvos nos favoritos e pré-carregados, e atualizar uma página GET é inofensivo.
• Use POST para ações que alteram o estado e para enviar cargas úteis sensíveis ou grandes. Atualizar ou voltar para uma página POST aciona o aviso do navegador "confirmar reenvio do formulário".
• Nunca envie senhas via GET — elas ficariam na URL, nos logs e no histórico. Isso é higiene, não criptografia: HTTPS criptografa tanto a URL quanto o corpo em trânsito, mas a URL ainda é registrada.

Perguntas frequentes

• Os métodos seguros são GET, HEAD, OPTIONS; os métodos idempotentes são GET, HEAD, PUT, DELETE; POST não é nenhum dos dois.
• Ambos os métodos são suportados por formulários HTML (o atributo method).
• "Seguro", no sentido da RFC, significa ausência de mudança de estado, não proteção de dados.
• A idempotência de POST no nível da aplicação costuma ser aplicada com chaves de idempotência.