4 ms·

> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. I’m already seeing implemento

> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, and to give reproducible results the server would need to save it. Now to make it idempotent, will be an ad-hoc decision of each server. It seems contradictory. At this point it’s indistinguishable from a PUT on a resource that represents the query itself. I’m not seeing the point of the new method.

n00bskoolbus 5y ago
Yeah it's already created confusion for me. I read it as essentially a side effect free request with a request body. Not that the data behind it was necessarily immutable but that the query didn't do any mutations.
- afiori 5y ago
  Idempotent is not "side effect free", but rather with only side effects that need to be safe to duplicate and deduplicate. As in "increase counter by 1" is not idempotent, "set counter to 2" and "set counter (monotonic*) counter to 2 if current value is 0" are idempotent. It is quite weak as a requirement for example an API that functionally must not be cached can still be idempotent.
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 ago
    If 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 ago
  I 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.
jmull 5y ago
Edit: never mind, my response was redundant by the time I finished it.
dragonwriter 5y ago
> I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, Safe requests (all of which are necessarily also idempotent) are not reliably reproducible; GET of the same resource changes if there are server-state changes induced by other requests between GETs. So, what you suggest is not failing to follow the spec.

n00bskoolbus 5y ago

Yeah it's already created confusion for me. I read it as essentially a side effect free request with a request body. Not that the data behind it was necessarily immutable but that the query didn't do any mutations.

afiori 5y ago
Idempotent is not "side effect free", but rather with only side effects that need to be safe to duplicate and deduplicate. As in "increase counter by 1" is not idempotent, "set counter to 2" and "set counter (monotonic*) counter to 2 if current value is 0" are idempotent. It is quite weak as a requirement for example an API that functionally must not be cached can still be idempotent.

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 ago
  If 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 ago
I 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.

jmull 5y ago

Edit: never mind, my response was redundant by the time I finished it.

dragonwriter 5y ago

> I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, Safe requests (all of which are necessarily also idempotent) are not reliably reproducible; GET of the same resource changes if there are server-state changes induced by other requests between GETs. So, what you suggest is not failing to follow the spec.