[stickfigure]

Your comment contributes nothing to the discourse. It's FUD.

The pattern I describe was the dominant design pattern for financial transaction processing systems before Stripe. Stripe's API makes life for the clients slightly easier at the expense of making life for servers more complicated, but the two approaches are equivalent in function.

[whoamii]

The topic is about idempotency though, and what you are describing is not idempotency. You are describing something different, and arguing “but it accomplishes a similar thing.” It appears you have come to the same conclusion as the article that building idempotency isn’t trivial.

[stickfigure]

It absolutely is idempotent behavior of the system. The goal is "make an idempotent payment", and this approach ("return an error for duplicates") was standard for financial APIs before Stripe. It still dominates for ecommerce APIs.

It isn't complicated, though I can see how if your entire experience with financial APIs is Stripe, you might not be aware of how simple it is. Because Stripe's approach, while mildly more convenient for clients, is a PITA to implement properly.

[whoamii]

You seem to believe idempotency is a fancy word for avoiding duplicates, which is why we seem to be having different conversations.

[stickfigure]

Idempotence is a fancy word for being able to repeat an operation without changing the outcome.

You seem to think that it's important to make the specific bytes of an http request-response idempotent.

I think that it's important to make a business operation idempotent.

You're missing the forest for the trees.