When designing REST endpoints idempotency is a crucial tool. Say we have a HTTP endpoint accepting PUT which we would like to be idempotent.
In case a client makes the same request multiple times, should the server always return the same, or is it acceptable to return an error the second time?
If the answer is yes is restapitutorial.com wrong in writing the following?
"From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource's state may change between requests"
If the answer is yes is a document database implementing optimistic concurrency using get+put not idempotent since the second call would result in an conflict?
If the answer is yes is there a term for services providing the lesser form of guarantee that making the same request more than once has the same effect on the server state as making it exactly once?
Best Answer
According to the HTTP 1.1 specification, idempotence is defined as: "(aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request". As this definition only discusses the side-effects of the request, and not the content returned, it is acceptable to return different content.