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

181–190 of 313 posts

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

#181

Post by nwsm »

bawana wrote: post #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?

I think there was a homepage with a "toggle" button, the toggle button redirected to /toggle.

site.com/toggle then got added to his favorites by safari.

So it wasn't loading the site with the button, but the site that the button redirects to.

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

#182

Post by chaosmonkey »

notheguyouthink wrote: post #148
beejiu wrote: post #15

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…

> Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in…

I think he only had GET /door/toggle, which cannot be idempotent.

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

#183

Post by oneeyedpigeon »

criddell wrote: post #149
jimktrains2 wrote: post #132

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.

I think having a URL that unsubscribes people just via a GET request is far more likely to cause problems, 'respectful', 'legal', or otherwise.

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

#184

Post by notheguyouthink »

chaosmonkey wrote: post #182
notheguyouthink wrote: post #148

Earlier quoted context omitted.

> Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in…

I think he only had GET /door/toggle, which cannot be idempotent.

Yea, but his point was that GET requests should be idempotent.. when that's not the important part of GET. That's why I used the example of GET /door/open, because that is idempotent, but it's still gross - it's causing a state change from a GET request while still being idempotent.

GET being idempotent is not the issue the author was dealing with. State change from a GET is the real issue.

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

#185

Post by eddz »

beejiu wrote: post #15

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…

> But GET should have no side-effect

I disagree. There are some ways in which GET can be non-idempotent, such as pageview counters and endpoints with a vast amount of constantly-changing content, for instance. One may argue that the first example may be possible with a GET followed by a POST, but any subsequent GET response (assuming it contains the counter) would still be different to its prior.

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

#186

Post by 0xcde4c3db »

ams6110 wrote: post #158
athenot wrote: post #151

Earlier quoted context omitted.

I remember having a similar issue in 2000, before any (meaningful) client-side javascript. Solution: each link that did something also had a request_id parameter, which was a timestamp in milliseconds. Two requests with the same request_id meant the user had clicked something twice, so any action would NOT be performed multiple times if the same request_id came in more than once. This let users double click on links…

A not-small percentage of users double click links (and buttons, and anything else that needs clicking).

The wording is a little ambiguous, but I think the scheme was that the first request is honored and any subsequent requests are ignored, not that additional requests cancel or undo the action altogether.

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

#187

Post by shocks »

pbhjpbhj wrote: post #131
shocks wrote: post #98

Earlier quoted context omitted.

Yeah, it's a sit/stand Linak desk. I hooked up an ESP32, 2 channel relay (up/down control), and distance sensor (to detect height). Pushes height to graphite and position is settable remotely. :)

It's been an hour, is your desk oscillating yet?

No, but I had to implement a lock feature because my colleagues apparently cannot be trusted...

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

#189

Post by shocks »

neilsimp1 wrote: post #172
shocks wrote: post #92

My desk height is set with a GET. I was going to fix it, but considering how hilarious this is I might not.

I get that it's cool, but I'm missing the why? Would you ever need to change your desk height when you're not already at your desk? Wouldn't manually changing the height be easier than hitting an HTTP endpoint on your PC to adjust it? Maybe I'm missing something, and like I said, I'll give oyu that it's cool and that alone is sometimes reason enough.

> I get that it's cool, but I'm missing the why?

I'm a hacker, I did it because it's cool and I wanted to learn.

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

#190

Post by mrybczyn »

hardwaresofton wrote: post #75
icc97 wrote: post #57

Earlier quoted context omitted.

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.

So I'm actually really interested in this conversation -- I think it's a good one that everyone has that needs to just get resolved. I think deciding where to follow and how much to follow REST/HATEOAS is exactly what engineering teams should decide. There are escape hatches (POST can do just about anything) and lots of ways to do things but REST-ful (not pure necessarily pure REST) and HATEOAS-y (usually comes up in…

SOAP-XML request handling in C on a 100mhz embedded microLinux MMUless processor with plenty of processor and shitty kernel arch bugs ruined my life for a year once.

I mean it's the obvious choice for a simple control UI implementation on a slow embedded system...

You may resume your javascript framework discussion now.

Post reply on HN