Re: the meaning of stateless

On Apr 22, 2013, at 4:44 PM, Will Hartung <[email protected]> wrote:
> Now, if you replace the name/address resource with "Shopping Cart" it's the same thing. A Shopping Cart is simply a combination Invoice and Pick List that's being built up over time. There is machine logic to keep the resource properly structured and semantically correct, but it's really a single resource that just getting changed over time. No big deal.

My current understanding of stateless is that there should not need to be "state" on the server that will cause a different behavior based on a user might take.  So POSTing to "new item" resource changes the server state because if a user then issues a PUT with a value of "status=order-submitted" something different happens than if they had NOT first POSTed to the new item resource. 

Further, if lots of users are adding items to shopping cart resources (think Amazon-scale) then the server has to scale up to hang on to these shopping cart states.

So how is that "stateless", honest question?

> However, each of the transactions that manage that resource are themselves stateless. Resource value is not the same as state.

I don't follow the distinction between resource value and state.  Maybe I need an example of "resource value" that differs from what you are calling state?

> You can easily see having any of a zillion web servers fronting the resource store that manages the Shopping Cart. Since there's no transaction state maintained with any one server, you can switch back and forth across them without any semantic change to the application.

But one database server has to keep track of the cart contents, right?

> Just like when you go to the Post Office. You get in line, and when you get to the clerk you ask to change your address. They tell you to fill out a form, and you go back in line. When you get back to a clerk, any clerk, the process continues. The state itself is the form you're holding. You don't have any requirement to go back to the same clerk.

But the post office has a central database somewhere and maintains that as "state," no?

> The transaction is the same thing. Think of the transaction as renting bowling shoes. In order to go bowling, you must have bowling shoes. So you "check out" the token (bowling shoes), and give them YOUR shoes as an "identifier", then you go back and swap them out. When you check your bowling shoes back in, you're done bowling. Any person at the counter can handle this transaction. The actual transactions themselves are stateless. You're just pushing resources back and forth.

So the "bowling shoes API" has to keep track of the "shoes" it lends with an internal IDs. 
How is this different from a session ID other that it's specific to aspects of the application vs. general? 

To be clear, I'm asking these questions to help understand not to challenge your assertions.

-Mike