3 ms·
"Idempotent" does not mean successive identical requests must return identical content. For example, two successive GET requests to the same URL will not return
by pdonis 5y ago
"Idempotent" does not mean successive identical requests must return identical content. For example, two successive GET requests to the same URL will not return identical content if in between them the owner of the website changes the page at that URL. Similarly, if the source of the request content is a mutable database, two successive QUERY requests with the same request content will not return identical content if the database is mutated in between by someone else.
All "idempotent" actually means is that successive identical requests must induce the same change in the server's state due to the request itself. In the case of verbs like GET and QUERY, that is trivially true since they induce no change in the server's state at all. But the content of the response can of course change due to other events happening on the server. If "idempotent" required that not to happen, no request could ever be guaranteed to be idempotent.
- wink 5y ago> that is trivially true since they induce no change in the server's state at all. Have you heard about visit counters? ;)
- pdonis 5y agoIf visit counters are considered to be changes in the server state, then servers that implement them are violating the requirement that GET requests must be idempotent.
- hcarvalhoalves 5y agoI mean: I don't see the point to have a new method that still gives the same (weak and misnamed) idempotency guarantees of GET. We already have GET, and a new method isn't necessary just to pass request data. I would rather have a method that _may_ have side-effect on the server-side, but it's actually idempotent from the client-side (as in, truly reproducible results). That already exists in the form of a PUT + some content addressing scheme, for example, but it's open to each implementation.