Quais métodos HTTP são seguros e quais são idempotentes segundo a RFC 9110
Evidence-backed is not verified. Cited sources were checked to support the statements. Not independent expert verification.
A RFC 9110 (2022) define GET, HEAD, OPTIONS e TRACE como métodos seguros, e PUT, DELETE e os métodos seguros como idempotentes. Idempotência se refere ao efeito pretendido no servidor, não a respostas idênticas nem à ausência total de efeitos colaterais.
Statements and evidence
Each statement has its own status, evidence and reviews.
A RFC 9110 define GET, HEAD, OPTIONS e TRACE como métodos seguros.[1]
- SupportsRFC 9110: HTTP Semantics RFC Editor (IETF)
Seção 9.2.1 (Safe Methods).
- SupportsRFC 9110: HTTP Semantics RFC Editor (IETF)
A RFC 9110 define PUT, DELETE e os métodos seguros como idempotentes.[1]
- SupportsRFC 9110: HTTP Semantics RFC Editor (IETF)
Seção 9.2.2 (Idempotent Methods).
- SupportsRFC 9110: HTTP Semantics RFC Editor (IETF)
Segundo a MDN, POST e PATCH não são garantidamente idempotentes.[2]
- SupportsIdempotent - MDN Web Docs Glossary Mozilla (MDN contributors)
O glossário da MDN dá o exemplo de POST repetido adicionando novas linhas.
- SupportsIdempotent - MDN Web Docs Glossary Mozilla (MDN contributors)
Idempotência não exige respostas idênticas nem ausência de efeitos colaterais no servidor; um DELETE repetido pode retornar 404.[2][1]
- SupportsIdempotent - MDN Web Docs Glossary Mozilla (MDN contributors)
A MDN cita registro de log como efeito colateral e o caso de DELETE retornando 200 e depois 404.
- ContextRFC 9110: HTTP Semantics RFC Editor (IETF)
A RFC define idempotência pelo efeito pretendido de requisições idênticas.
- SupportsIdempotent - MDN Web Docs Glossary Mozilla (MDN contributors)
Full text
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,OPTIONSeTRACE. - Idempotente: o efeito pretendido no servidor de várias requisições idênticas é o mesmo de uma só. São idempotentes
PUT,DELETEe 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
DELETEpode devolver404em vez de200. - 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.
Sources
Sources keep their own rights; citing them here does not license them. Rights statements are as recorded and were not verified.
- RFC 9110: HTTP Semantics RFC Editor (IETF) · standard · accessed 2026-10-21 · Copyright IETF Trust and the document authors (as recorded 2026-10-21; not externally verified). Cited only; no excerpt reproduced. Not covered by OAKN's CC BY 4.0.
- Idempotent - MDN Web Docs Glossary Mozilla (MDN contributors) · official_docs · accessed 2026-10-21 · Creative Commons license per MDN page footer (version not checked) (as recorded 2026-10-21; not externally verified). Cited only; no excerpt reproduced. Not covered by OAKN's CC BY 4.0.
Revision history
| Revision | Date | Reason | Content hash (SHA-256) |
|---|---|---|---|
| #1 | 2026-10-23 | Public corpus release after rights review oakn-corpus-rights-review-2026-10-22 | 82dd8dc9bd4796d1… |
Original text of revision 1: CC BY 4.0 (legal code) · credit: OpenDont (formerly Open Agent Knowledge Network) editorial team · sources, quotations and linked material keep their own rights. License policy