Re: Does idempotence include the response codes?

On 17/10/2013 9:24 p.m., Philippe Mougin wrote:
> Le 16 oct. 2013 à 05:34, Amos Jeffries <squid3@treenet.co.nz> a écrit :
>
>> On 16/10/2013 11:31 a.m., Philippe Mougin wrote:
>>> Le 15 oct. 2013 à 23:24, Mark Nottingham <mnot@mnot.net> a écrit :
>>>> On 15/10/2013, at 1:17 PM, Gili <cowwoc@bbs.darktech.org> wrote:
>>>>
>>>>> Yes. Adding "on the server" and an example would definitely help.
>>>> Seems like a reasonable editorial clarification to me.
>>> It wouldn't work as it would include in its scope methods that actually are not idempotent.
>> Which ones and how?
> Methods idempotent with regard to state of the server but not idempotent with regard to other parts of reality.
>
> For example, if I define a new request method, LAUNCH, with the following semantics : "The LAUNCH method requests that a new missile is prepared and launched. The LAUNCH method does not request modifications to the state of the server".

... resulting in 1 less missile available in the resource on "the 
server" ... which is a state change for the server.
The assertion "Methods idempotent with regard to state of the server" is 
false for this example.

Even if "the server" is shifted down into the missile itself it has 
undergone a state change from WAITING to LAUNCHED. Possibly with 
implicit LANDED or ABORTED state changes timing down.

> This method would match the newly proposed definition of idempotent. However, if we consider the intended effect in general, launching multiple missiles has not the same effect as launching one missile. Therefore we do not want this method to be considered idempotent.

To be idempotent with regard to the server your method URI would have to 
indicate _which_ missile to launch. Then telling the same missile to 
launch multiple times should have no different effect than telling it 
once. That is an idempotent method, both in regards to the server state 
and to reality beyond the server.

> PS: I do not encourage people to design methods that launch missiles.

Too late. You did.

Amos

Received on Thursday, 17 October 2013 11:49:18 UTC