Why Is HTTP POST Not Idempotent While PUT Is?
An HTTP method is idempotent if executing it multiple times produces the exact same server state as executing it once. PUT is idempotent because repeating a PUT replaces the target resource at a known URI, whereas repeating a POST creates additional new subordinate resources or appends duplicate records each time.
Detailed Technical Explanation
According to RFC 9110, idempotency refers to the side-effects on the server. If a client sends `PUT /users/42` with `{"name": "Alice"}` five times in a row, the record at `/users/42` will always contain `{"name": "Alice"}`; the system state is identical after 1 call or 5 calls. However, if a client sends `POST /orders` five times without an idempotency key, the server will process 5 distinct orders, charge the customer's credit card 5 times, and create 5 separate database IDs. This is why browsers warn users: "Do you want to resubmit this form?" on page refreshes after POST, but never after PUT or GET.
Technical Example & Code
Comparing resource mutation behaviors in RESTful APIs.
// 1. POST (Non-Idempotent): Appends/creates new subordinate resources
POST /api/v1/orders HTTP/1.1
// Call 1 -> Order #1001 created
// Call 2 -> Order #1002 created (duplicate order!)
// Call 3 -> Order #1003 created (another duplicate!)
// 2. PUT (Idempotent): Replaces the resource at the explicit URI
PUT /api/v1/orders/1001 HTTP/1.1
{"status": "shipped"}
// Call 1 -> Order #1001 status set to "shipped"
// Call 2 -> Order #1001 status remains "shipped" (no side-effects!)
// Call 3 -> Order #1001 status remains "shipped"Why This Is the Case (Underlying Architectural Rationale)
"Network connections are inherently unreliable and drop packets. When an idempotent request (like PUT or GET) times out without a response, the client can automatically and safely retry the request without human intervention. Because POST is non-idempotent, automated retries could trigger double payments or duplicate transactions."
Common Misconception vs Reality
"PUT and PATCH are interchangeable synonyms for updating data."
PUT is idempotent and replaces the entire resource representation; PATCH (RFC 5789) is non-idempotent by default and applies a set of delta modifications to an existing resource.
Related Curious-Techie Resources
Related Questions in the Q&A Knowledge Base
Last-Modified is a timestamp-based cache validator with 1-second resolution, while ETag is an arbitrary content-based fingerprint (such as a hash) that accurately detects byte-level changes even when modifications occur multiple times in the same second or across distributed server clusters.
HTTP 401 Unauthorized means the user is not authenticated (identity unknown; credentials missing or invalid), whereas HTTP 403 Forbidden means the user is authenticated (identity known), but lacks the necessary permissions to access the requested resource.
Yes, HTTPS encrypts the entire HTTP request—including the URL path, query parameters, request headers, cookies, and message body. Only the destination hostname (domain name) and port number are visible on the wire via the TLS Server Name Indication (SNI) extension.
Ecossistema Técnico Relacionado e Próximos Passos
Artigos Técnicos Relacionados
What Is HTTP (Hypertext Transfer Protocol)?
Foundational stateless request-response protocol of the World Wide Web.
HTTP/1.1 vs HTTP/2: Multiplexing & Performance
Head-of-line blocking compared to binary framing and stream multiplexing.
Troubleshooting: HTTP 403 Forbidden Error
Diagnose server authorization denial, WAF IP blocks, and permission issues.
Laboratórios Práticos de Diagnóstico
Especificações e Referências para Desenvolvedores
Continuar Aprendendo
HTTP Protocol & Header Inspection Lab
Craft raw HTTP headers and observe conditional 304 responses in the interactive workbench.