Partager via

Idempotence on HTTP operations

  • Article

A few folks sent me email asking about idempotence on Astoria operations over the HTTP/REST interface, motivated by this post. I completely agree that idempotence is an important characteristic of an interface as it allows you to make a bunch of assumptions on the consuming side. That said, there are practical limits to what we can do, and there are some assumtions that come backed on the protocol to some extent.

Here is what the Astoria interface does from the idempotence perspective:

Whether operations on the underlying data (from a database or otherwise) are effectively idempotent is beyond the control of Astoria. While on the Astoria runtime side we define whether *we* consider an operation could be idempotent, the underlying data source in the end is who'll determine whether the operation is effectively idempotent or not.

  • GETs are side-effect-free, so they are out of the discussion.
  • PUTs are idempotent from the Astoria perspective, but the underlying data source could do something that breaks that (e.g. a trigger in a database that counts the number of changes...or simple a timestamp value).
  • DELETEs are the same as PUT. Idempotent from Astoria, but the datasource could break that effect.
  • POSTs are definitely not expected to be idempotent, and the HTTP spec explicitly calls that out. We use POST as this interpretation described in the spec: " Extending a database through an append operation ". Such operation is non-idempotent by definition. In the case where the client generates all the record, including the keys, you can re-try safely because the second try will fail if the first went through...but that's more circumstantial idempotence than real.

Does this sound reasonable?

-pablo

Comments