
Using Atomic Transactions to Power an Idempotent API - mikecarlton
https://brandur.org/http-transactions
======
omtinez
I fail to understand the need to re-use terms from other fields in a
completely twisted way. For those like me wondering what an "idempotent API"
is: making multiple identical requests has the same effect as making a single
request[1].

Then you have other people using the exact same term to refer to a (seemingly)
totally different concept: An idempotent operation completes no more than one
time[2].

Maybe I'm thicker than the average web developer, but I think that there must
be a simpler way to explain this concept. Specially without reusing a term
that, formally, means something completely different[3] than any of the
possible interpretations that I have come up with so far.

[1]
[http://www.restapitutorial.com/lessons/idempotency.html](http://www.restapitutorial.com/lessons/idempotency.html)
[2]
[http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_In...](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
[3]
[https://en.wikipedia.org/wiki/Idempotence](https://en.wikipedia.org/wiki/Idempotence)

~~~
eropple
I teach a lot of pretty middling software developers about idempotence when
discussing configuration management tools, and it seems pretty graspable.
Idempotence is `f(f(x)) = f(x)` and nothing but. This is your #1.

Upon a second read, what AWS is saying is "if you pass a token and this has
already been done with that token, return the original result." That token is
just setting part of `x`.

~~~
omtinez
By your definition, how can a REST API be idempotent? Say that GET(user) =
john so, what I'm interpreting is that: GET( GET(user) ) = GET(john) = john.
That doesn't seem valid to me.

~~~
nawgszy
GET requests are a bad example because usually GET(x) will always return the
same thing, unless x was updated in some fashion

Let's work with the classic TODO app example. Say the user adds a TODO item,
and makes a POST request to the server to store it. If the user POSTs their
TODO, but due to your front-end being overly-eager to hear back from the
server, it sends the request twice because the first one took too long to
respond.

This should not create two identical TODO items, but instead only create one.
This is the concept of idempotence; performing the same operation n (n > 0)
times should be the same as performing it once.

It's slightly notationally inaccurate to say f(f(x)) is what the client is
performing in this case, it's more like f(x) * f(x), but these details surely
are unimportant.

------
depsypher
Is it common for people to solve concurrency problems in the database by using
serializable txn isolation? I'm genuinely curious. I realize you should always
measure these things for your specific use case, but I've always thought that
was a non-starter from a performance perspective. What are the real tradeoffs
these days with it?

~~~
mayank
Check out the TPC benchmark:
[http://www.tpc.org/information/benchmarks.asp](http://www.tpc.org/information/benchmarks.asp)

