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.
You know how HTTP GET requests are meant to be idempotent?
11–20 of 313 posts
Re: You know how HTTP GET requests are meant to be idempotent?
#12Idempotency 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.
Re: You know how HTTP GET requests are meant to be idempotent?
#13Is 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.
Re: You know how HTTP GET requests are meant to be idempotent?
#14Is idempotency part of HTTP or just part of loose REST conventions?
Part of HTTP: https://github.com/for-GET/know-your-http-well/blob/master/m...
For a fascinating overview how all of HTTP fits together I also recommend the HTTP decision diagram: https://github.com/for-GET/http-decision-diagram/blob/master...
Re: You know how HTTP GET requests are meant to be idempotent?
#15When 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 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.
Re: You know how HTTP GET requests are meant to be idempotent?
#16Idempotency 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.
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 (application/merge-patch+json):
Re: You know how HTTP GET requests are meant to be idempotent?
#17I’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..
Re: You know how HTTP GET requests are meant to be idempotent?
#18When 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).
Re: You know how HTTP GET requests are meant to be idempotent?
#19Earlier 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…
Just be the guy who says "oh a POST is fine" first
Re: You know how HTTP GET requests are meant to be idempotent?
#20I’m more surprised that the Safari new tab window makes GET requests to every “favorite” URL, which I gather is what was happening.
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.