[twic]

> The possible creation of extra HTTP resources (response resorces?) seems to me contrary to idempotency.

If two repetitions of a QUERY request create the same extra HTTP resource(s), then it can be idempotent.

Idempotent means you can't tell the difference between 1 or N requests, not that you can't tell the difference between 0 and 1. Think about PUT, which is also idempotent.

[jasonhansel]

Still, it is odd that a GET-like method is allowed to have side effects.

[dragonwriter]

GET is (and all methods, including all safe and idempotent methods, are) allowed to have side effects, per the spec. Safe and idempotent are not mathematical constructs as defined in HTTP, they are more “business” constructs.

[twic]

I know what you mean. It feels like we're missing an idea of scope for resources. If there was some kind of transaction scope or session scope or something, then a QUERY could create resources within that scope, so we could know that in the long run, it has no side effects. But that would be antithetical to the idea of statelessness perhaps.

Or maybe we just need distributed garbage collection for URLs.

[wizzwizz4]

> Or maybe we just need distributed garbage collection for URLs.

Printing a URL on paper leaks it. Writing a URL down, or memorising it, also leaks it – but the computer has no way of knowing this has happened.

I don't think this is feasible.

[jpitz]

GET is allowed to have side effects, just not beyond the first invocation of a given request.

[dragonwriter]

> GET is allowed to have side effects, just not beyond the first invocation of a given request.

GET can have side effects, and has no difference first and subsequent invocations (because it is safe as well as idempotent). Were it idempotent but not safe, it could have side effects that the client was accountable for the first request, but no different ones of that kind for subsequent uses.

[jpitz]

Yes, and to that end, the draft defines QUERY as both idempotent AND safe.

[scheme271]

But pretty much every http request has side effects if you consider logging.

[nybble41]

The way I look at it is that the system must continue to meet its requirements (whatever they might be) whether it gets one GET request or many in response to a single action within the user agent (clicking a link, submitting a form, script making a request, etc.). In general, logging two requests instead of one does not violate any requirements and in fact logging every request, even duplicates, is the expected behavior. Adding the same item to a list twice in response to a single UI interaction, on the other hand, would not give the desired effect.