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

71–80 of 313 posts

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

#71

Post by hardwaresofton »

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…

Totally valid question -- it was indeed a throwaway remark but is pretty bitter in tone now that I think about it.

To delve into what I was thinking a little bit I think it came off so bitter because I've been in too many orgs where group-thinking squashed dissenting possibly-correct opinions, where half the room is wondering "this seems too complex, why are we doing this" but everyone goes with it. Reading through the twitter comments had a bunch of people were trying to gloss over the misuse and it might have triggered me.

The more reasonable response is definitely to articulate and explain why a GET is NOT fine in that case so everyone learns, but once this starts happening a lot I mark it as a red flag in my head -- it's either a culture clash or I'm too close to being the most experienced in the room (in that specific area), and that means there are less people to learn from and staying for too long might lead to stagnating. The "leave the org" bit is hyperbole, but I worry about this kind of thing if I experience it.

In the end though, it was meant to be a humorous post so the remark is overblown.

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

#72

Post by thomasz »

rusk wrote: post #44
dewiz wrote: post #34

Earlier quoted context omitted.

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

I'd just like to clarify that what you have described here is "safe" rather than "idempotent" [0]. Easy mistake to make, made the same mistake myself, idempotently (that is to say you only make it once ;) Get, and NOOP, are both "safe" and naturally "idempotent" since the former encompasses the latter. [0] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

GET must be safe and idempodent. In the context of http, idempodency basically means that you get the same result for each request with the same url and the same set of parameters.

Toggle should be implemented as post, since it’s neither safe, nor idempodent.

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

#73

Post by laneb »

mseebach wrote: post #68
someonewithpc wrote: post #45

Earlier quoted context omitted.

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

I think that is considered idempotent in the REST-sense of the word: you can multiply a number by two as many times as you like, the result will be the same (and no state is mutated). I looked it up, apparently there's a formal definition "denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself", which does not seem to describe the REST usage very well, though.

The typical operation applied to sets of functions is composition, so idempotency of a function f is the condition that f(f(x)) = f(x) for all x in the domain of f. I don't think that applies meaningfully to GET.

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

#74

Post by StavrosK »

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.

I dispute your example. If you call f(2) and it always returns 4, it's idempotent and side-effect-free. If you call f() and it returns 4, then 8, etc, it is neither.

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

#75

Post by hardwaresofton »

icc97 wrote: post #57
aptwebapps wrote: post #21

Earlier quoted context omitted.

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.

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 terms of pagination/relations first) APIs are not bad at all.

I think JSON+JSON-LD still offers some benefits over XML at the very least in the security sense -- while it can be misused, there are much less dynamic bits built in to the transfer language itself.

Also I'd say that JSON "scales" well in terms of complexity still, small things are cognitively light, and big things are linearly more cognitively heavy.

Is JSON+JSON-LD+X the new XML?

Is Swagger the new WSDL/SOAP?

I dunno, but it doesn't feel like it's quite that bad yet.

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

#76

Post by rusk »

thomasz wrote: post #72
rusk wrote: post #44

Earlier quoted context omitted.

I'd just like to clarify that what you have described here is "safe" rather than "idempotent" [0]. Easy mistake to make, made the same mistake myself, idempotently (that is to say you only make it once ;) Get, and NOOP, are both "safe" and naturally "idempotent" since the former encompasses the latter. [0] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

GET must be safe and idempodent. In the context of http, idempodency basically means that you get the same result for each request with the same url and the same set of parameters. Toggle should be implemented as post, since it’s neither safe, nor idempodent.

yes

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

#78

Post by mbid »

StavrosK wrote: post #74
someonewithpc wrote: post #45

Earlier quoted context omitted.

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

I dispute your example. If you call f(2) and it always returns 4, it's idempotent and side-effect-free. If you call f() and it returns 4, then 8, etc, it is neither.

From wikipedia:

"A unary operation f, that is, a map from some set S into itself, is called idempotent if, for all x in S, f(f(x)) = f(x)."

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

#79

Post by mcintyre1994 »

onion2k wrote: post #64
z3t4 wrote: post #56

Earlier quoted context omitted.

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.

It's trivial to debug a POST in a browser if you can open the console. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

And if you're in a browser with a console worth opening you can use fetch instead which is way nicer: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Also Postman is awesome for debugging REST APIs.

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

#80

Post by mvindahl »

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.

Absolutely agree. A PUT method carrying an open/closed flag would seem like a natural choice. Calling it any number of consecutive times with the same payload would be idempotent. There would probably be a GET method to go along with it. And of course, it would model the desired state, not the actual position of the garage door since garage doors don't instantaneously flip (would be cool though).
Post reply on HN