Hacker News Reader

First off, the HTTP specification requires that GET (and HEAD) requests be idempotent to enable caching.

Technically, PUT request are supposed to be idempotent, while GET and HEAD are supposed to be side-effect free (which is strictly stronger than idempotency).

View on HN

PUT is supposed to be idempotent? So an "increment" or "reverse" request should technically be a POST?

Or does the idempoten-cy apply only to the response from the server, and not the state of the data on the server?

PUT is supposed to be idempotent? So an "increment" or "reverse" request should technically be a POST?

Absolutely. User-agents are allowed to retry PUTs transparently -- it's only for POSTs that they're supposed to put up a "are you sure you want to re-submit this form? Bad stuff might happen" dialog.

That's certainly my understanding of it. PUT has semantics of resource creation or updating, like writing a file: whatever you upload replaces what is already there, if anything. You can process the data of course, but the outcome should depend only on the request data itself, not state.

Thanks for correcting the definition of idempotence in my brain! (edited original post)

Reply on news.ycombinator.com