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

21–30 of 313 posts

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

#21

Post by aptwebapps »

groestl wrote: post #19
hardwaresofton wrote: post #16

Earlier quoted context omitted.

At the risk of being overly pedantic/piling on -- this is what bad REST-ful API design looks like in practice. When you talk to your teammates about the semantics of these verbs and someone just says "oh a GET is fine" and the team agrees but you don't and you can't say it so you don't become "that guy" it's time to find a new engineering org to be a part of. On the topic of PATCH, check out JSON merge patches (appli…

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.

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

#22

Post by poizan42 »

javajosh wrote: post #18
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…

It would be sufficient to GET a resource that uses a script to POST the side-effect. Slack's user-agent probably isn't sophisticated enough to mess this up (although heaven help us when they implement their preview with something like headless chrome).

What would the problem be in just showing a button that says "Confirm unsubscribe" that sends a POST request? A lot of sites does something like that for their newsletter unsubscription.

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

#23

Post by Senderman »

hardwaresofton wrote: post #16
onion2k wrote: post #12

Earlier quoted context omitted.

Exactly. A 'toggle' should really be implemented as a PATCH request, or maybe a PUT if there's no data other than the door state.

At the risk of being overly pedantic/piling on -- this is what bad REST-ful API design looks like in practice. When you talk to your teammates about the semantics of these verbs and someone just says "oh a GET is fine" and the team agrees but you don't and you can't say it so you don't become "that guy" it's time to find a new engineering org to be a part of. On the topic of PATCH, check out JSON merge patches (appli…

I hope this doesn't come across as mean-spirited, but I'm really struck by the middle part of your comment, even though I think it was meant as a throwaway remark.

It sounds like you're advocating leaving an organisation instead of speaking up when a mistake is being made? In the scenario you described, the "a GET is fine" person is unfamiliar with the protocol they're writing for (HTTP), and so is every person who agreed. Leaving instead of speaking up seems pretty drastic.

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

#24

Post by ignoramous »

onion2k wrote: post #12
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.

Exactly. A 'toggle' should really be implemented as a PATCH request, or maybe a PUT if there's no data other than the door state.

One more thing: PATCH needs to do atomic updates on a partial resource per http://restcookbook.com/ (which I think is a great TLDR resource on the topic).

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

#25

Post by peteretep »

phamilton wrote: post #13
guelo wrote: post #6

Is idempotency part of HTTP or just part of loose REST conventions?

> loose REST conventions REST is HTTP. "loose REST conventions" is when someone chose to ignore big chunks of the HTTP spec. In other words, you can build whatever you want (like SOAP) on top of HTTP and ignore the spec that describes content negotiation, HTTP methods, Caching policies, etc. It's still technically HTTP. But if you were to read the HTTP spec and follow it to a tee, you'd build a REST application.

> REST is HTTP

This is untrue. I hate to quote from Wikipedia, but it sums it up quite nicely: "REST is not a standard in itself, but RESTful implementations make use of standards, such as HTTP, URI, JSON, and XML"

More colloquially: REST is what happens when people mix up transport layers in their head.

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

#26

Post by Senderman »

josteink wrote: post #20
jedberg wrote: post #8

Earlier quoted context omitted.

It's updating the thumbnail screenshots. This only happens if you have the Safari "blank page" be your favorites instead of either your "home page" or a truly blank page.

> if you have the Safari "blank page" be your favorites instead of either your "home page" or a truly blank page. Yay for modern user friendly applications making simple words like blank completely meaningless and ambiguous.

The commenter may have called it a "blank page", but Safari doesn't; it just labels the setting as "New tabs open with...", with "Empty page" being one of the choices.

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

#27

Post by samb1729 »

Senderman wrote: post #23
hardwaresofton wrote: post #16

Earlier quoted context omitted.

At the risk of being overly pedantic/piling on -- this is what bad REST-ful API design looks like in practice. When you talk to your teammates about the semantics of these verbs and someone just says "oh a GET is fine" and the team agrees but you don't and you can't say it so you don't become "that guy" it's time to find a new engineering org to be a part of. On the topic of PATCH, check out JSON merge patches (appli…

I hope this doesn't come across as mean-spirited, but I'm really struck by the middle part of your comment, even though I think it was meant as a throwaway remark. It sounds like you're advocating leaving an organisation instead of speaking up when a mistake is being made? In the scenario you described, the "a GET is fine" person is unfamiliar with the protocol they're writing for (HTTP), and so is every person who a…

My interpretation is that GP is advocating leaving an org if you feel that speaking up is discouraged

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

#28

Post by kalleboo »

mozumder wrote: post #17
baddox wrote: post #4

I’m more surprised that the Safari new tab window makes GET requests to every “favorite” URL, which I gather is what was happening.

Now I wonder if Safari (& other browsers) has distinct headers for their favorites lookups, to tell these lookups apart from real users and discard these accesses from site analytics..

They do, "X-Purpose: preview"

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

#29

Post by wpearse »

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.

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

#30

Post by wpearse »

baddox wrote: post #4

I’m more surprised that the Safari new tab window makes GET requests to every “favorite” URL, which I gather is what was happening.

Hey! I've been thinking about this all day. I thought it was a GET to fetch the title of the page, but it might only be an OPTIONS or HEAD request? I'm not sure. Either way, my code activates the garage door on that endpoint no matter the HTTP verb.
Post reply on HN