You have to think about one action when thinking about idempotency.
If you call DELETE 100 times, it will still be the same item that is deleted, you remove it from memory, the DB or set a field deleted = true or something. Same goes for PUT, you send an update to the server, but you "set" state to a new state, you don't do stuff like "increase value x", "append string to y" or "subtract 10 from z".
Sure the data will be gone for your next GET request if you issued 1 or 100 DELETEs, but the idea is that the 100 DELETEs end in the same state as the 1 DELETEs
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
You can go to your parents and ask the same thing, in the same way, any number of times.
If nothing else changes, the act of asking something over and over will not change the answer. They won't even get annoyed.
Very nice metaphor. Perhaps a small addition: You can go to your parents and ask the same thing, in the same way, any number of times. If youβre sure they were listening at least once, then you can be sure that they will take care of whatever it is you asked.
Notably, the same might also be true for non-idempotent verbs; the difference is that there you donβt have the guarantee that it will always behave idempotently.
A great example of an idempotent function is the absolute value function. abs(-4) = 4abs(4) = 4. Continuing to apply abs() onto itself will always yield the same result.
For those that have done some Elixir before: -4 |> abs |> abs |> ... will always yield 4
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (8)
Ask someone to turn a switch on, they do, and the switch is on.
Ask them to turn it on again and your command has no effect.
That's idempotency.
Idempotency just means, calling the same function/endpoint multiple times, with the same arguments, will result in the same state.
if you write an endpoint like
/player/increaseScoreByOne
it will change the state as often as you call it.if you write an endpoint like
/player/setScoreTo?value=100
it will always result in the same state.When your request doesn't get through, you can safely make it again without worrying about an inconsistent server state.
Not for 5 year olds, but I hope it helps xD
First of all, thank you for answering.
Considering your reply,
Idempotent: GET, TRACE, OPTIONS
Non-Idempotent: DELETE
Where do I place DELETE and PUT, and why?
You have to think about one action when thinking about idempotency.
If you call
DELETE
100 times, it will still be the same item that is deleted, you remove it from memory, the DB or set a fielddeleted = true
or something. Same goes forPUT
, you send an update to the server, but you "set" state to a new state, you don't do stuff like "increase value x", "append string to y" or "subtract 10 from z".Sure the data will be gone for your next
GET
request if you issued 1 or 100DELETE
s, but the idea is that the 100DELETE
s end in the same state as the 1DELETE
sGotcha!! Thanks buddy :)
The 5-year-old explanation could be:
You can go to your parents and ask the same thing, in the same way, any number of times.
If nothing else changes, the act of asking something over and over will not change the answer. They won't even get annoyed.
:)
Very nice metaphor. Perhaps a small addition: You can go to your parents and ask the same thing, in the same way, any number of times. If youβre sure they were listening at least once, then you can be sure that they will take care of whatever it is you asked.
Notably, the same might also be true for non-idempotent verbs; the difference is that there you donβt have the guarantee that it will always behave idempotently.
A great example of an idempotent function is the absolute value function.
abs(-4) = 4
abs(4) = 4
. Continuing to applyabs()
onto itself will always yield the same result.For those that have done some Elixir before:
-4 |> abs |> abs |> ...
will always yield4