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…
You know how HTTP GET requests are meant to be idempotent?
161–170 of 313 posts
Re: You know how HTTP GET requests are meant to be idempotent?
#162Earlier 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…
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?
#163what does this mean
Re: You know how HTTP GET requests are meant to be idempotent?
#164Earlier 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.
Re: You know how HTTP GET requests are meant to be idempotent?
#165Two 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.
Re: You know how HTTP GET requests are meant to be idempotent?
#166Earlier 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(…
Re: You know how HTTP GET requests are meant to be idempotent?
#167Is 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?
#168Re: You know how HTTP GET requests are meant to be idempotent?
#169Re: You know how HTTP GET requests are meant to be idempotent?
#170I 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…
There is also REPLACE INTO
Assuming you have a relevant unique key setup of course.