On 08/03/2009, at 11:14 AM, Damien Katz wrote:
The problem is if there is a network error, a client has no way to
if a POST commit was successful. The success or failure response can
get lost, and the id of the document is completely unknown to the
client.
This is a different problem than the double post - would the same
problem not occur if the client failed? e.g. if there's no way of
finding the resultant document, then the failure modes seem symmetric.
But if the client knows the doc id beforehand, then it can later
check the db (or reattempt the update) to see if the update was
successful or lost. And wIth deterministic rev ids, the client could
just do the update again and get a success response despite the
update maybe already having being committed.
This suggests that the POST without an id should be removed from the
API. Most of the other APIs have revs, which protect the model from
this bug, resulting in mere user confusion. And this prompts a thought
about a similar problem with replicate/compact/purge et al. Maybe a
generic solution could be to allow a client supplied UUID in the
request, which is retained in the server for some short time (in
network terms) to make POSTs generically idempotent over some window?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There is nothing more difficult to plan, more doubtful of success, nor
more dangerous to manage than the creation of a new order of things...
Whenever his enemies have the ability to attack the innovator, they do
so with the passion of partisans, while the others defend him
sluggishly, So that the innovator and his party alike are vulnerable.
-- Niccolo Machiavelli, 1513, The Prince.
