RE: Proposed text on reliability in the web services architecture

> Ok, something short and sweet like;
>
> "Web services that wish to inherit the properties of the REST
> architectural style, can achieve a degree of reliability without the use
> of some or all of the features of a reliable messaging facility.  For
> example, if the service was to make its data accessible via PUT (an
> idempotent method), then clients can simply reinvoke the method should
> it not be clear if the previous message was successful or not.  For
> non-idempotent methods such as POST, some of the expected features of
> a reliable messaging facility could be reused; specifically, a message
> identifier mechanism."

I am not sure I understand. We already pointed out to the distinction
between operation and method.

I can make the method idempotent using message ID, so if you are not sure
whether or not you sent the message, you just send it again. Duplicate
messages will be ignored (at most once semantics). So the method is
idempotent. That's precisely how you would do it if you have asynchronous
messaging, whether you're using HTTP POST without transaction coordination
or SMTP.

But that doesn't make the operation idempotent. If you are sending the same
message twice then you are performing the same operation once. If you are
sending two different messages then you are performing the same operation
twice. This is where idempotent becomes a factor. Depositing money in an
account is a good example.

You can send the deposit message three times with the same side effect,
since multiple messages are deposit. You can also deposit the same amount
twice, and that's not idempotent. Each time you will have a bigger balance.
That's the distinction we're trying to make. To determine whether the
operation, not the message passing, is idempotent.

arkin

Received on Thursday, 9 January 2003 17:37:54 UTC