CyberCertPrepWeb App FundamentalsAPIs & RESTEASYFree question
What does 'idempotency' mean for HTTP methods, and which standard methods are defined as idempotent by RFC 9110?
- A.Idempotent means the method returns the same response every time
- B.Idempotent means multiple identical requests have the same server-state effect as a single request. RFC 9110 defines as idempotent: GET, HEAD, PUT, DELETE, OPTIONS, TRACE. POST and PATCH are not inherently idempotent. Note: idempotent does not mean same response - DELETE on an already-deleted resource might return 404 on second call, but the server state is identical
- C.Only GET and HEAD are idempotent; all other methods create state changes
- D.Idempotency is only relevant for POST requests using idempotency keys
Why B is correct
RFC 9110 idempotency: the server state is the same whether you make the request once or multiple times. GET/HEAD/OPTIONS: read-only (no state change). PUT: replace resource - replacing with the same content twice = same state. DELETE: delete resource - deleting twice = still deleted (404 on second call, but state is identical). Practical importance: clients can safely retry idempotent requests after network failures without risk of duplicate effects. Non-idempotent methods (POST: creates new resources; PATCH: partial updates depending on implementation) require explicit idempotency keys for safe retry.
Know someone studying for Web App Fundamentals? Send them this one.