You know how HTTP GET requests are meant to be idempotent?

Re:You know how HTTP GET requests are meant to be idempotent? by thomasz on Tuesday May 01, 2018 @04:08AM (#16965322)

“Toggle” is by definition not idempodent, because you get a different result each and every time. “Open” and “close” are idempodent, but not safe. The result of a GET request should always be idempodent and safe.

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by dewiz on Tuesday May 01, 2018 @04:18AM (#16965354)

GET requests should have no side effects. In other words NOOP is idempotent

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by rusk on Tuesday May 01, 2018 @04:31AM (#16965402)

I'd just like to clarify that what you have described here is "safe" rather than "idempotent" [0]. Easy mistake to make, made the same mistake myself, idempotently (that is to say you only make it once ;)

Get, and NOOP, are both "safe" and naturally "idempotent" since the former encompasses the latter.

[0] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by thomasz on Tuesday May 01, 2018 @05:41AM (#16965647)

GET must be safe and idempodent. In the context of http, idempodency basically means that you get the same result for each request with the same url and the same set of parameters.

Toggle should be implemented as post, since it’s neither safe, nor idempodent.

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by mpweiher on Tuesday May 01, 2018 @06:45AM (#16965934)

> get the same result for each request with the same url and the same set of parameters.

I think the resource can change externally...so it means that your GET request doesn't change it, but it doesn't have to be the same result every time.

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by dalore on Tuesday May 01, 2018 @08:38AM (#16966493)

No not the same result. How would the front page of any news site work then?

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by rusk on Tuesday May 01, 2018 @05:48AM (#16965675)

yes

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by thomasz on Tuesday May 01, 2018 @04:34AM (#16965415)

IIRC, the rfc uses “safe” instead of “side effect free”, which is very similar, but not exactly the same.

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by jimktrains2 on Tuesday May 01, 2018 @08:36AM (#16966480)

Get should be safe, but that's not the same as indempotent. Delete requests are also indempotent as the final state will always be the same.

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by bad_user on Tuesday May 01, 2018 @07:29AM (#16966139)

Reading from a database isn’t “side effect free”, neither is reading from a mutable variable.

Given that HTTP requests are supposed to trigger database reads that may return a different result after some time, then “side effect free” would indeed be incorrect.

The litmus test is ... does it always return the same output given the same input? If that can change, the it’s not describing a pure function, but a side effectful one.

And the output of a GET request can and does change.

Speaking of which people here aren’t talking of idempotency in a mathematical sense:

f(f(x)) == f(x)

If you really think about it, GET requests aren’t even idempotent ;-)

[ Parent | on HN ]

Re:You know how HTTP GET requests are meant to be idempotent? by icebraining on Tuesday May 01, 2018 @08:04AM (#16966301)

Having no side-effects means it doesn't cause side-effects, not that it can't be "victim" to them. It's no the same as purity.

[ Parent | on HN ]