Quais métodos HTTP são seguros e quais são idempotentes segundo a RFC 9110

Definições da RFC 9110

A RFC 9110 (HTTP Semantics, publicada em junho de 2022 pela IETF) separa duas propriedades dos métodos de requisição:

• Seguro (safe): o cliente não pede nem espera mudança de estado no servidor. Entre os métodos definidos na própria RFC, são seguros GET, HEAD, OPTIONS e TRACE.
• Idempotente: o efeito pretendido no servidor de várias requisições idênticas é o mesmo de uma só. São idempotentes PUT, DELETE e todos os métodos seguros.

Logo, todo método seguro é idempotente, mas nem todo idempotente é seguro: DELETE altera estado, porém repeti-lo não altera mais do que a primeira vez.

O que fica de fora

POST não é definido como idempotente: enviar duas vezes o mesmo formulário de pedido pode criar dois pedidos. A MDN também lista PATCH como não garantidamente idempotente, porque um patch pode ser relativo (por exemplo, "incrementar contador").

Por que isso importa

A propriedade orienta retentativas automáticas. Clientes, proxies e bibliotecas podem repetir com mais tranquilidade um GET ou PUT que falhou por timeout; para métodos não idempotentes, a RFC recomenda não repetir automaticamente sem algum meio de saber que é seguro. Em APIs, é comum complementar POST com uma chave de idempotência enviada pelo cliente.

Limites e ressalvas

• Idempotência trata do efeito pretendido, não da resposta: um segundo DELETE pode devolver 404 em vez de 200.
• Efeitos colaterais incidentais, como gravar log ou métricas, não tornam um método não idempotente.
• A especificação descreve semântica; ela não impede que um servidor mal implementado faça algo não idempotente num GET. Quem implementa a API é responsável por respeitar essas garantias.
• Métodos definidos em outras especificações (por exemplo PATCH, RFC 5789) têm suas propriedades definidas nesses documentos.