Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idempotency is easy until the second request is different

blog.dochia.dev

Post reply on HN
Print view View original

71–80 of 244 posts

Re: Idempotency is easy until the second request is different

#71

Post by TacticalCoder »

shiandow wrote: post #4

This seems to assume retrying a command should result in the same response, but I am not sure I agree. Idempotency is about state, not communication. Send the same payment twice and one of them should respond "payment already exists".

Not that it's a bad TFA but in addition to what you said, many/most of the edge cases mentioned in TFA are just as problematic whether idempotency is desired or not.

I mean:

> Maybe the first request created a local payment but crashed before publishing an event ...

I mean, yeah, sure. That's a problem. I can come up with another one:

"Maybe the ZFS disk array for the DB caught fire and died a horrible death and you now need to restore from backups".

But that's going to be a problem anyway.

Re: Idempotency is easy until the second request is different

#72

Post by doginasuit »

This article seems to be missing an example use-case for this functionality, it is very unclear to me that this is a good idea. Your job is hopefully to build an API with the simplest and most reliable contract to meet the needs of the client. Sometimes that involves saying, "human technology does not have a reliable way to support this expectation, but here's what else could work."

Re: Idempotency is easy until the second request is different

#73

Post by raffael_de »

Hendrikto wrote: post #58
conradludgate wrote: post #49

Earlier quoted context omitted.

There's no side effects in f here, so the statement does not apply

Parent said > State is in practice always subjected to side effects and concurrency. There was never any claim or assumption regarding f. Maybe the way you interpreted it is what they meant, but it is not what was stated.

you are oversimplifying with your set variable example. the context is complex state management as with online purchases.

Re: Idempotency is easy until the second request is different

#74

Post by mrkeen »

raffael_de wrote: post #53
mrkeen wrote: post #33

Earlier quoted context omitted.

1) Fresh UUID 2) Client's choice

now you are moving the core question to where the fresh UUID is calculated. a UUID is calculated or reused based on a process-defined decision.

It's not the 'core question'.

I can choose to purchase a 2nd item, or I can choose to retry purchasing the 1st item. The server making that choice for me is not idempotency.

Idempotency is the server supporting my ability to retry purchasing the 1st item, safe in the knowledge that they won't send me a 2nd one.

Re: Idempotency is easy until the second request is different

#76

Post by randallsquared »

zarzavat wrote: post #75
randallsquared wrote: post #65

If the second request is different, then idempotency doesn't apply.

How would you even know the second request is different? Hash every request? That's a waste of resources. The only sensible policy is to trust the key.

No, the sensible policy is to have the code operate idempotently for every request with an idempotent method. This is a design decision, not something you slap on top afterward with a special key.

Re: Idempotency is easy until the second request is different

#77

Post by zarzavat »

randallsquared wrote: post #76
zarzavat wrote: post #75

Earlier quoted context omitted.

How would you even know the second request is different? Hash every request? That's a waste of resources. The only sensible policy is to trust the key.

No, the sensible policy is to have the code operate idempotently for every request with an idempotent method. This is a design decision, not something you slap on top afterward with a special key.

I believe you need to read the article. The article is about the Idempotency-Key header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

Re: Idempotency is easy until the second request is different

#78

Post by pvillano »

xlii wrote: post #48

Don't fix other people problems. If idempotent key was seen then send back response. Clients intention is outside the scope. If contract says "idempotency on key" the idempotent response on key. If contract says "idempotent on body hash" then response on body hash (which might or might not include extra data). APIs are contracts. Not the pinky promise of "I'll do my best guess"

I would rather do more work myself to make an API as fool proof as possible, than hope everyone else is perfect, and lose data when they're not.

Re: Idempotency is easy until the second request is different

#79

Post by cookiengineer »

xlii wrote: post #48

Don't fix other people problems. If idempotent key was seen then send back response. Clients intention is outside the scope. If contract says "idempotency on key" the idempotent response on key. If contract says "idempotent on body hash" then response on body hash (which might or might not include extra data). APIs are contracts. Not the pinky promise of "I'll do my best guess"

> APIs are contracts. Not the pinky promise of "I'll do my best guess"

You have never had to work with PHP backends, have you?

JSON in PHP is a flustercluck. Undefined, null, "" or "null", that is always the question.

If you use a typed Go/Rust client and schemas, you usually end up with "look ahead schemas" that try to detect the actual types behind the scenes, either with custom marshallers or with some v1/v2/v3 etc schema structs.

It's so painful to deal with ducktyped languages ... that's something I wouldn't wish on anyone.

Re: Idempotency is easy until the second request is different

#80

Post by wizzwizz4 »

frwickst wrote: post #38
vanviegen wrote: post #22

> If you’re still in school, here’s a fact: you will learn as much or more every year of your professional life than you learned during an entire university degree—assuming you have a real engineering job. This rubs me the wrong way. It's stated as fact without any trace of evidence, it is probably false, and it seems to serve no purpose but to make struggling students feel worse (and make the author feel superior).

What you learn at a uni is not really about learning a trade, sure it gives you a taste of the basics in many areas, but you will never be an supeb developer (or another profession) when you get out by only attending classes. However, what uni teaches you is how to learn, how to think critically, how important sources are, what to look for to get the most knowledge out of what you read. Or at least that is what it ha…

That's what university is supposed to be about, but it doesn't achieve that for many people. Which is a shame, because those skills are extremely important.
Post reply on HN