[brainwipe]

In HTTP idempotent is where the state of the server remains unchanged. A resource in HTTP is what you get back from an URL, so https://example.com/people/show/10 (where 10 is the page number) is a different resource to https://example.com/people/show/100.

If I interpret it correctly - adding more resources isn't changing the server state but adding more ways of getting to the state.

[CrazyStat]

> In HTTP idempotent is where the state of the server remains unchanged.

This is incorrect. DELETE is idempotent but changes the state of the server.

[dragonwriter]

Also PUT.

[dragonwriter]

> In HTTP idempotent is where the state of the server remains unchanged

No, it's not. That's closer to “safe” than “idempotent” (safe also implies idempotent, but not the other way around), but even then it is not quite right, because even safe methods are allowed to have side effects, but their is guidance about the kind and impact of side effects that it shouldn't have.

[danidiaz]

So that means that, without a cache, repeating a QUERY might create two response resources but, with a cache, only one will be created. I find that odd. My understanding of HTTP idempotency is that it's more of a "whole-server" concept (excepting perhaps things like creation of log entries and metrics). Always creating a new resource for each request seems contrary to that.

A way to square creation of response resources with idempotency could be: the second identical QUERY that arrives should always reuse the result resource created by the first QUERY.

[CrazyStat]

What if the underlying data has changed?

If I QUERY the current price of a stock, and then someone else sends an identical QUERY ten seconds later, they might get a different result. This is not because QUERY isn't idempotent.

[danidiaz]

I think that, when talking about idempotency, there's the implicit assumption that the "rest of the world" stays the same while the sequence of operations is performed.

rfc2616 says:

> Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

https://datatracker.ietf.org/doc/html/rfc2616#page-51

Perhaps changes in the underlying data could be considered "expiration issues". Otherwise not even GET could be considered idempotent in many cases.

[CrazyStat]

Idempotency is not about "you get the same result", it's about the effects of your http request on the server. Notice that the definition you quoted is in terms of side-effects, not results.

If a request changes the state of the server and another identical request changes the state of the server in a different way, it's not idempotent.

If a request doesn't change the state of the server at all it is idempotent, even if subsequent requests might get different responses (e.g. the stock quote example in my previous post).

If a request changes the state of the server but repeated identical requests don't have any different effect it is also idempotent. For example, DELETE is idempotent because DELETE-ing something N times is the same as deleting it one time.

[samhw]

I think this is pointing to the problem with your definition of 'idempotent'. Idempotency simply means that any number of additional identical requests will have the same effect on the state of the resource, not that they will have no effect. (And by 'have the same effect', we mean 'produce the same state', not 'alter state in the same way' - effects are algebraic projections.)

That's why it's called idempotent - 'doing the same' - rather than impotent.

[dragonwriter]

> rfc2616 says:

“Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235”