Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

51–60 of 313 posts

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

#51

Post by latchkey »

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 header as well, thanks for the suggestion.

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

#52

Post by amelius »

someonewithpc wrote: post #45
bjackman wrote: post #39

Earlier quoted context omitted.

Anything side-effect-free is idempotent too, I suppose

No. A function which multiplies a number by two is side effect free, but is no idempotent.

Except if the domain is zero.

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

#54

Post by keithnz »

dogma1138 wrote: post #46
xbenjii wrote: post #41

Earlier quoted context omitted.

I hope that's not your real password!

Well according to Google it’s an address in Auckland NZ so I hope it’s not his address either.

hey, I'm in Auckland,maybe I can go around and hack his garage :)

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

#55

Post by wpearse »

speps wrote: post #43
xbenjii wrote: post #41

Earlier quoted context omitted.

I hope that's not your real password!

EDIT: it's actually his address, I thought it was just a coincidence but you can the house on Street View... I removed the actual name as doxxing isn't great, sorry.

Thanks. Not the address with the WiFi garage thankfully.

I was actually thinking "better not commit that" ... before, y'know, I committed it :/

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

#56

Post by z3t4 »

groestl wrote: post #11

Idempotency might be necessary for GET calls, but it's not sufficient. Imagine he had two separate GET calls (opened/closed): the author would still have the same problem. Browsers assume GET to be safe (non-mutating), and safety implies idempotency.

HTTP GET is nice because you can "debug" via browser. But I don't think it's a good protocol choice for opening/closing doors nor any other service not related to document requests.

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

#57

Post by icc97 »

aptwebapps wrote: post #21
groestl wrote: post #19

Earlier quoted context omitted.

Just be the guy who says "oh a POST is fine" first

Yeah, full REST is nice, but you can do worse than just using GET and POST as long as GET doesn't change state.

Layers of REST that people get to:

1. GET is good for everything

2. Perhaps we should use POST too

3. Let's use all the verbs

4. Someone mentions HATEOAS

5. Some old guy says that you've got to use XML because that defines links and JSON doesn't

6. Someone else counters with JSON-LD and sends a link to the W3 spec

That's as far as I got. Mostly this conversation happens in my head.

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

#58

Post by MrMid »

Well, a while ago I saw this code (on my own project!): window.open("?controller=users&action=changePassword&name=" + user_name + "&password=" + password)

I was horrified, glad it isn't live yet, and I fixed it immediately. But I'm still wondering whether I was so sleep-deprived or drunk when I wrote this. It's over SSL, so it should not be that big deal, but still, GET shouldn't be used for such things.

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

#59

Post by XorNot »

latchkey wrote: post #51

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…

This still seems like really bad idea when the POST request is right there.

Serve a page with a button saying "are you sure"?

Post reply on HN