Re:Idempotence: What is it and why should I care?
by haswell on Tuesday August 21, 2018 @08:28AM
(#17808931)
For HTTP resources, this is addressed in RFC7231 - essentially, servers may implement non-idempotent behavior such as logging for methods otherwise considered idempotent.
Re:Idempotence: What is it and why should I care?
by not_kurt_godel on Monday August 20, 2018 @09:13PM
(#17805909)
A more idempotency-friendly API would be:
setAccountLockStatus('user', LockStatus.LOCKED)
Re:Idempotence: What is it and why should I care?
by morokhovets on Tuesday August 21, 2018 @01:31AM
(#17807240)
Or maybe ensureAccountLocked('user')?
How about state changes as a side effect, with a near meaningless result.
LockAccount('user')
The account is now locked.
LockAccount('user')
Error: The account was already locked!
However, the internal state of the user after the second operation remains the same. We also cannot use any of the information in the result as something meaningful as shown in these math equations because the API has a wall over an opaque data structure. Which is often not the case in Math. Similar to chmod, there might be a low-level file API that throws an internal error because the file is already executable, but the chmod wrapper hides that possible error. (It probably doesn't have an error internally, but for argument sake).