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

111–120 of 313 posts

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

#111

Post by criddell »

bjackman wrote: post #42
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…

Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

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

#112

Post by criddell »

XorNot wrote: post #59
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"?

Do you really like having to confirm every action? For interfaces that you use all the time, it's nice to be able to eliminate extra steps.

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

#113

Post by mysterydip »

criddell wrote: post #111
bjackman wrote: post #42

Earlier quoted context omitted.

Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

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

#114

Post by slig »

AnIdiotOnTheNet wrote: post #110

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.

Adding Wi-Fi control to your garage door using a WeMos is not over-engineering. It's just a fun little weekend hack.

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

#115

Post by icebraining »

mysterydip wrote: post #113
criddell wrote: post #111

Earlier quoted context omitted.

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

Confirmation steps should only be used if the action can't be easily undone.

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

#116

Post by cjrp »

mysterydip wrote: post #113
criddell wrote: post #111

Earlier quoted context omitted.

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

The majority of people who clicked on the link did it on purpose, so a better pattern would be to make it unsubscribe immediately with a "didn't meant to unsubscribe? click here to undo" link afterwards.

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

#117

Post by a13n »

AnIdiotOnTheNet wrote: post #110

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.

1) Market disagrees with you strongly, hence hundreds of millions of people using it regularly.

2) He's just having fun, working on a side project that's useful to him, and learning. Nothing wrong with any of that.

Why so negative?

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

#118

Post by elmigranto »

mysterydip wrote: post #113
criddell wrote: post #111

Earlier quoted context omitted.

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

Have a single "I clicked by mistake" button that resubscribes instead.

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

#119

Post by icebraining »

bad_user wrote: post #107
dewiz wrote: post #34

Earlier quoted context omitted.

GET requests should have no side effects. In other words NOOP is idempotent

Reading from a database isn’t “side effect free”, neither is reading from a mutable variable. Given that HTTP requests are supposed to trigger database reads that may return a different result after some time, then “side effect free” would indeed be incorrect. The litmus test is ... does it always return the same output given the same input? If that can change, the it’s not describing a pure function, but a side effe…

Having no side-effects means it doesn't cause side-effects, not that it can't be "victim" to them. It's no the same as purity.

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

#120

Post by NoGravitas »

criddell wrote: post #96
bushin wrote: post #36

Earlier quoted context omitted.

> you'd build a REST application Nah, nerds would come out of the woodwork to inform you that what you've built is not a real REST.

Yeah - there's always a HATEOAS comment somewhere and I've never really managed to figure out what that means beyond using URI's rather than a database IDs + some documented endpoint path to point to other resources.

This should help: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
Post reply on HN