Re:Using Atomic Transactions to Power an Idempotent API
by omtinez on Thursday September 14, 2017 @07:04PM
(#15253206)
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.
Re:Using Atomic Transactions to Power an Idempotent API
by nawgszy on Thursday September 14, 2017 @07:21PM
(#15253304)
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.
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`.