- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Wed, 30 Aug 1995 11:11:54 PDT
- To: liberte@ncsa.uiuc.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Let me try to guess at some of the operational motivation behind the
concept we're trying to define for GET vs POST.
Right now, there are browsers around with a 'reload' button. If you
'reload' something that you obtained using 'GET', then you might get
different results, but it is 'safe' to press reload. However, if you
'reload' something that you obtained using 'POST', then you might not
want to blindly resubmit the same form data. Many browsers either
complain or ask 'Resubmit FORM data?' when asked to 'reload' something
obtained using '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.
The property 'idempotent' can only apply when functions have a range
that is a subset of their domain.
If you define
value-returned = f<value> (server-state-before-GET )
you'll note that range of 'value-returned' is a different
datatype/class and is disjoint from the domain of
'server-state-before-GET'.
Received on Wednesday, 30 August 1995 11:14:24 UTC