Re: Comments on draft-v10-03a.

Larry Masinter writes:
 > Let me try to guess at some of the operational motivation behind the
 > concept we're trying to define for GET vs POST.

 > ...

 > Translating back from this usage scenario to a set of operational
 > requirements leads me to thinking that we want 'GET' to have no
 > additional side effects if repeated.
 > 
 > This is only vaguely related to the notion of idempotency. If you
 > define:
 >
 >     server-state-after-GET = f<state> ( server-state-before-GET ) 
 > 
 > and ask that f<state> be idempotent. Note that the idempotency only
 > applies to the 'server state' and not to the value returned.

Right.  This no-side-effects property might be called server-state
idempotence, if you want to confuse people.  Let's be explicit and
call the tag: "side-effects".  This is independent of and orthogonal
to "no-cache" which implies the result will be different each time.
(Actually, "no-cache" could simply mean don't keep a copy, for
whatever reason.)

But similar to no-cache, I dont believe we should assume or require
that GET has no side-effects, or that POST always does.  I can think
of contrary cases for each.

dan

Received on Wednesday, 30 August 1995 11:38:01 UTC