Live data from Hacker News

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

twitter.com

161–170 of 313 posts

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

#161
post #150

The real problem here, as usual, is web browsers, the worst class of software ever written. We constantly come across these CSRF-style bugs that are only made possible by how stupid the browser and HTTP are, but instead of blaming the culprit and trying to deal with the source, we blame ourselves for not being accommodating enough. Fool me once, shame on me, fool me 5,000 times, shame on me. Oh, and occasionally inve…

Nay. TFA correctly identifies the problem.

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

#162
post #136

Earlier quoted context omitted.

> I should have used "side-effect-free" instead of "idempotent" in my tweets The HTTP term is "safe method". Although you weren't even wrong because section 4.2.2 of RFC7231 (i.e. HTTP) defines all safe methods, including GET, as idempotent. I think they use this language because nothing is truly side-effect free. In fact GETs can have side-effects, the most obvious of which is writing the fact of it to a logfile, an…

'Side-effect free' means that doing it once, twice or n >= 3 times (with same parameters) yields the same result, i.e. what it returns doesn't depend on any remote state that is altered by the call itself . However, an idempotent HTTP call is certainly not a pure function which some people seem to be mixing up. Pure functions don't work with I/O. REST is bit more specific and explicitly requires GET to be nullipotent…

> Pure functions don't work with I/O.

there is a comment above that argue this point in better details.

https://news.ycombinator.com/item?id=16966046

Basically it depends on the many nuances you have on "pure", "functions" and "idempotent"

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

#164

Earlier quoted context omitted.

You're making the mistake that this very article is highlighting: it's not just "people" who click links. An overzealous mail client or browser preloading links would force unsubscribe you without your knowledge or ability to undo. A single step, a button push, to confirm an unsubscription is fine.

> A single step, a button push, to confirm an unsubscription is fine. No, it really isn't. Lots of mailing lists operate exactly as the person you replied to mentioned where after unsubscribing you are given a chance to undo that action. That's a far more respectful way to operate.

What definition of fine are you using?

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

#165

Two thoughts: 1) Twitter is a terrible medium for anything, let alone posts longer than a sentence. 2) The level of over-engineering tech people readily engage in without a second thought is truly mind boggling.

Over-engineering can only be assessed based on the goals of the project, which he hasn't detailed.

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

#166
post #94

Earlier quoted context omitted.

Yes, in mathematics, not programming. And a function that doubles a number isn't idempotent even by that definition.

Of course a doubling function is not idempotent! I think the confusion arises because side-effectful functions can be considered as having type f :: (RealWorld, OtherArgs) -> (RealWorld, OtherOutputs) and so for a garage door toggle you have something like t :: RealWorld -> RealWorld where the new state is the old one with the door opened/closed as appropriate. Now the idempotence condition becomes: t(t(world)) == t(…

But `GET(GET(x))` doesn't make sense, in general (and if it did, then you would not expect it to be idempotent), so clearly idempotency in this context is meant to mean side-effect free. They should probably just say side-effect free, though, to avoid the confusion.

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

#167
forgive my density, but why would you make a web page trigger a toggle when it is loaded? shouldnt there be a button or some other user interaction to initiate the state change?

Is it like loading a web page for the weather- so that when the page is loaded it goes and 'GETS' the latest weather info? Is it for convenience? So that all you have to do is go to a webpage and have it do stuff?

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

#168
I know this is quite unrelated, and based on hazy memory of things from almost 10 years ago, DML statements in databases especially 'insert into' statements are not idempotent as I remember; ie if you try to select a few rows from a table table1 and insert them into table2 with same schema, if there were any identical rows already in table2, then whole insert will fail. My thinking at that time was that if these insert operations were idempotent, then there would be no need to explicitly check for duplicates before the insert.

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

#169

Earlier quoted context omitted.

Yes, the automated system prefetching links will always click said button.

Not if the button issues a POST request.

The button I was responding about was an "undo unsubscribe". A bot won't click that button, but may follow a link.

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

#170

I know this is quite unrelated, and based on hazy memory of things from almost 10 years ago, DML statements in databases especially 'insert into' statements are not idempotent as I remember; ie if you try to select a few rows from a table table1 and insert them into table2 with same schema, if there were any identical rows already in table2, then whole insert will fail. My thinking at that time was that if these inse…

At least in MySQL you can use “ON DUPLICATE KEY” to either ignore such things or optionally execute an update statement to change something about the matching row.

There is also REPLACE INTO

Assuming you have a relevant unique key setup of course.

Post reply on HN