Re: Re: the meaning of stateless

a _representation_ of the contents of the shopping cart should be shipped
from the client to the server when checking out.

there are lots of ways to represent the shopping cart contents. an HTML
representation, a binary compressed body, even just a hash. in fact, the
last method is the one i use most often.

<form action="..." method="post" class="checkout">
  <input type="hidden" name="carthash" value="...." />
  <input type="submit" />
</form>

in practice, client apps often need to request the cart contents in order
to receive the hash. but those clients can store this "representation" of
the cart locally, wait a few days, and then attempt the checkout action. as
long as the representation is still valid (e.g. the hash of the contents -
which might include pricing, taxes, etc.) the request succeeds.  if it
fails, the client is instructed to retrieve the current copy of the cart
(w/ new info, pricing, etc.) and try again.

Think airline tickets, concert seats, etc.



mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Thu, May 9, 2013 at 2:30 PM, Bob Haugen <[email protected]> wrote:

> On Thu, May 9, 2013 at 1:27 PM, Matt McClure <[email protected]>
> wrote:
> > It seems to me that a client need not include all of the detail of the
> cart
> > contents and payment method in the purchase request to conform with a
> > statelessness constraint. I'd be happy to hear why I'm wrong if I am.
>
> That was my position in the argument with Mark Baker that I lost.
>
> When I say "I lost", I decided I agreed with Mark that to be stateless
> and self-describing, the message to the server *did* need to include
> all the detail of the cart contents, payment method, etc. etc. etc.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>