- From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
- Date: Wed, 30 Aug 95 13:34:57 CDT
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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