As an aside, it is almost never appropriate to implement such a concept
using server-side state. It doesn't scale, it defeats caching, and it
results in a lot of unnecessary retrievals of the current state. The
Netscape cookie mechanism has all but the first problem as well.
What should be done is define a market basket / shelf media type,
allow this type to be embedded in an HTML document, and let the client
implement its own methods of manipulating the items in the shelf
such that they can be dropped in their own basket. The items could
then include sufficient information regarding payment mechanism and
cashier URL, such that the transaction of purchasing the items in
your market basket is simply a POST of that basket + payment info
to the cashier's URL, suitably encrypted and signed.
In this way, all but the last action is cacheable and the available
payment mechanisms are made clear prior to the user's purchase action.
>In any case, my prefered solution would be to use some response header
>to indicate the URI of the resource being returned.
That was already decided (for other reasons) at the HTTP-WG meeting
and is reflected in the new HTTP/1.0 draft 01 at
http://www.ics.uci.edu/pub/ietf/http/
ftp://www.ics.uci.edu/pub/ietf/http/
or
http://www.w3.org/hypertext/WWW/Protocols/Overview.html
See the Location header.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
([email protected]) ([email protected])