Re: the meaning of stateless

All mentions of state within the context of REST is TRANSACTION state. A
TRANSACTION is a process that CHANGES (Creates, changes, or deletes) a
RESOURCE.

The value of a resource is NOT "STATE". The back end application as
represented by resources and resources have values, and REST systems then
offer up REPRESENTATIONS of those values.

Consider, you can have a Clock resource.

http://example.com/currenttime

The stateless nature of the application is NOT the values of the Resources
themselves. It's obvious in the case that the application is managing the
"current time" (which is even more fun because the value of this resource
continually changes) and can give however many REPRESENTATIONS of that
resource.

But the REST architecture mandates that the transactions themselves, those
units of work that query or change the value are stateless. That means that
all the information necessary to carry out the transaction, is contained
within the request itself.

The "Change of Address" transaction at the Post Office is a stateless
transaction, because the form, when properly filled out, is all of the
information that is necessary to perform the transaction. You can take that
form to ANY Post Office and the System will act upon it appropriately. You
don't have to do it from your original post office, from it's city, or
state. Any Post Office in the system can handle that request. There are no
prerequisites.

All it requires is a properly filled out form. If the form is not valid,
the System will reject the form. At which point you can go fix the form and
start over (get back in line). Or you can come back tomorrow. Or you can
mail it in. Or you can drive to Prudhoe Bay in Alaska and drop it off
there. The end effect is the same, your address will be changed. The fact
that you've tried before, and where you've tried before, has no bearing on
the request itself, nor who you gave the request too.

Of course the Post Office maintains, somewhere, somehow, the relationship
between you and where you live. But that is not "state" in this context. I
consider that the value of the resource. (To help disambiguate between the
two in discussions.)

If you want to consider the combination of Resource values managed by the
Application as "The State of the Application", then that's fine. But that
"State" is not the same "state" that we talk about when discussing the
"stateless" nature of REST architectures.




On Mon, Apr 22, 2013 at 2:22 PM, Mike Schinkel <[email protected]> wrote:

> **
>
>
> 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
>
>  
>

-- 
CONFIDENTIALITY NOTICE: The information contained in this electronic 
transmission may be confidential. If you are not an intended recipient, be 
aware that any disclosure, copying, distribution or use of the information 
contained in this transmission is prohibited and may be unlawful. If you 
have received this transmission in error, please notify us by email reply 
and then erase it from your computer system.