4 ms·

“It does not matter if the operation is called only once, or 10s of times over. The result SHOULD be the same.” The result MUST be the same.

by zepto 5y ago

jefftk 5y ago
I think that's too strong: the response may have a component that is is non-deterministic. The important thing is that no matter how many times you call it the server state is the same.
- bastawhiz 5y ago
  Agreed. The state since the original success may have been mutated by another request since (or simply changed state as a result of any other async process), and the response may simply be a rendering of the latest server state. The response of the server absolutely should not be specified as being identical, since that's not how idempotent requests work. At that point, you're really just specifying a caching key for verbs that have side effects.
- sam0x17 5y ago
  Yeah, it's more about there being no side effects after the first time than asserting anything about the actual response
- zepto 5y ago
  If you distinguish the ‘response’ from the result, then I agree. Typically I think of the result as denoting the effect, and not the response message.
jhayward 5y ago
> The result MUST be the same. Transient errors happen, as well as loss of state errors, and a good protocol allows for that fact.
Spivak 5y ago
Request 1: Status: OK Modified: True Request: 2 Status: OK Modified: False Request 3: Status: EAGAIN Modified: False Request 4: Status: TOOFAST Modified: False Request 5: Status: EACCESS Description: Your OAuth token has expired. Modified: False
SvenL 5y ago
I think this is due to side effect which are not “undoable”, like sending an e-mail. In case the timeout happen when the response is send, an email might be already send. If the request is send again another email is send. I think that’s why the RFC says “result” and not “state”.
- lazide 5y ago
  Then it is a fundamentally non-idempotent operation? In the case if an email you could use the idempotency key in the accounts outbox so you could detect if you’ve already sent the message and then no-op if that is the case, and you’re idempotent. The response must reflect something useful, which is probably going to be different in those two cases.
  - skybrian 5y ago
    Yes, writing status to log would be a better example; you might want to log retries.
bhk 5y ago
The context is a paragraph describing a mathematical concept, not specifying the protocol. Any standardese imperative (SHOULD/MUST/...) is out of place here. It should read "The result is the same."
mst 5y ago
I suspect it's meant to include behaviours like this: https://news.ycombinator.com/item?id=27730372 https://news.ycombinator.com/item?id=27730372

“It does not matter if the operation is called only once, or 10s of times over. The result SHOULD be the same.” The result MUST be the same.

by zepto 5y ago

“It does not matter if the operation is called only once, or 10s of times over. The result SHOULD be the same.” The result MUST be the same.

jefftk 5y ago

I think that's too strong: the response may have a component that is is non-deterministic. The important thing is that no matter how many times you call it the server state is the same.

bastawhiz 5y ago
Agreed. The state since the original success may have been mutated by another request since (or simply changed state as a result of any other async process), and the response may simply be a rendering of the latest server state. The response of the server absolutely should not be specified as being identical, since that's not how idempotent requests work. At that point, you're really just specifying a caching key for verbs that have side effects.
sam0x17 5y ago
Yeah, it's more about there being no side effects after the first time than asserting anything about the actual response
zepto 5y ago
If you distinguish the ‘response’ from the result, then I agree. Typically I think of the result as denoting the effect, and not the response message.

jhayward 5y ago

> The result MUST be the same. Transient errors happen, as well as loss of state errors, and a good protocol allows for that fact.

Spivak 5y ago

Request 1: Status: OK Modified: True Request: 2 Status: OK Modified: False Request 3: Status: EAGAIN Modified: False Request 4: Status: TOOFAST Modified: False Request 5: Status: EACCESS Description: Your OAuth token has expired. Modified: False

SvenL 5y ago

I think this is due to side effect which are not “undoable”, like sending an e-mail. In case the timeout happen when the response is send, an email might be already send. If the request is send again another email is send. I think that’s why the RFC says “result” and not “state”.

lazide 5y ago
Then it is a fundamentally non-idempotent operation? In the case if an email you could use the idempotency key in the accounts outbox so you could detect if you’ve already sent the message and then no-op if that is the case, and you’re idempotent. The response must reflect something useful, which is probably going to be different in those two cases.
- skybrian 5y ago
  Yes, writing status to log would be a better example; you might want to log retries.

bhk 5y ago

The context is a paragraph describing a mathematical concept, not specifying the protocol. Any standardese imperative (SHOULD/MUST/...) is out of place here. It should read "The result is the same."

mst 5y ago

I suspect it's meant to include behaviours like this: https://news.ycombinator.com/item?id=27730372 https://news.ycombinator.com/item?id=27730372