3 ms·
Posting this to drive people crazy :) (only kidding) How about state changes as a side effect, with a near meaningless result. LockAccount('user') The accoun
by rhacker 8y ago
Posting this to drive people crazy :) (only kidding)
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).
- clord 8y agoYour error changed the state S of the world.
- not_kurt_godel 8y agoA more idempotency-friendly API would be: setAccountLockStatus('user', LockStatus.LOCKED)
- morokhovets 8y agoOr maybe ensureAccountLocked('user')?
- haswell 8y agoFor HTTP resources, this is addressed in RFC7231 - essentially, servers may implement non-idempotent behavior such as logging for methods otherwise considered idempotent. https://tools.ietf.org/html/rfc7231#section-4.2.2 https://tools.ietf.org/html/rfc7231#section-4.2.2