81–90 of 313 posts
> "I threw the code together in minutes and was too lazy to spend another couple minutes figuring out POST." So it's not the vendor's problem then. They provide you with two ways to make a request. You have a choice to do it right, you didn't.
Earlier quoted context omitted.
I think that is considered idempotent in the REST-sense of the word: you can multiply a number by two as many times as you like, the result will be the same (and no state is mutated). I looked it up, apparently there's a formal definition "denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself", which does not seem to describe the REST usage very well, though.
The typical operation applied to sets of functions is composition, so idempotency of a function f is the condition that f(f(x)) = f(x) for all x in the domain of f. I don't think that applies meaningfully to GET.
1) the original developer's idea of handling an unauthorized /admin request was just to set a redirect header and continue processing the current request .
2) the /admin page had a grid of all the content on the site, with handy 'Delete' links that ran over GET without confirmation.
You can probably guess where this is going – some search bot hit the overview page, ignored the redirect header, saw the content, and dutifully crawled every single link on it…
I’m more surprised that the Safari new tab window makes GET requests to every “favorite” URL, which I gather is what was happening.
Earlier quoted context omitted.
I dispute your example. If you call f(2) and it always returns 4, it's idempotent and side-effect-free. If you call f() and it returns 4, then 8, etc, it is neither.
From wikipedia: "A unary operation f, that is, a map from some set S into itself, is called idempotent if, for all x in S, f(f(x)) = f(x)."
Hello! Long-time lurker, and guilty dev behind the garage door. You can see the (broken) code I wrote here: https://github.com/wpearse/wemos-d1-garage-door-wifi I'll get around to fixing it later this week. Also, an apology: 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, and that's the most harmless side-effect of all, right until you run out of disk space.
Being a language arse I think the high precision descriptor is actually nullipotent. https://en.wiktionary.org/wiki/nullipotent but I'd never say it out loud.
I have a small (golang) agent that runs on over a thousand raspberry pi class machines (not on the open internet). The agent has a GET /reboot api because it is really convenient to be able to just hit that url in a browser window when we need to. Adding all the no-cache headers to the response seems to have worked well enough to prevent browsers from randomly hitting the url. I just added a check for the x-purpose h…
When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…
Earlier quoted context omitted.
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
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.
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.