> It's unclear to me as well. As long a the service creates a resource
> identifier for that cart (resource identification in REST), all the
> client needs to do is use it in subsequent requests. In my view,
> creating resources identifiers for things of interest is precisely how
> you avoid relying on sessions. The service will associate that resource
> identifier with objects stored in a database, and there's no need for
> the client to store anything once it gets that resource identifier.
If you want to put more items in the cart, the server must load the cart
from the hard drive using your identifyer (the server must "remember"). That
is what is called "stateFUL". Writing that SESSION information to disk and
loading it back later will need lots of time and drive space (remember, your
server might have to server lots of clients at any time). But if the cart is
kept solely on the client, that needed place is on each single client, and
the needed time is "on the network". You just scale much better.
> By analogy, let's say you call your insurance company to file a claim.
> The first time you call, you give them all your info and they give you
> a claim number (a resource identifier!). Next time you call, it does
> not really matter who you talk to as long as you give them the claim
> number and they can look it up in their database. Without a claim
> number, you'd need to start all over or talk to the same person to
> continue the session --and that wouldn't very RESTful.
Don't mix up things! What "Stateless" means is not the claim number! The
"state" is more like the state of the single call you do: Whether you
already have told the lady what claim it is about, whether she has noted you
latest information you told her, whether you like to quit the insurance now,
etc. It is *not* about state between calls. It is about state *while* the
duration of one call (and I suspect, you will say more than "hello" but
actuall have a discussion when you phone your insurance company).