Re: the meaning of stateless

These are both fine. The stateless attribute is an attribute of the
transaction in place, not a specific resource.

For example

It's safe to say that someone's name and address as a resource is a pretty
straight forward resource:

http://example.com/people/willhartung

It's also straight forward to consider that I can PUT a new copy of that
resource when I move, changing the city and state etc. within the resource.
Right?

It's also not inconceivable to have other operations that may make changes
to that resource. Perhaps if I add a business address through a separate
mechanism, the name resource may get added to it.

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.

However, each of the transactions that manage that resource are themselves
stateless. Resource value is not the same as 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.

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.

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.



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

> **
>
>
> This has been a really insightful thread.  Thank you Brian for starting it.
>
> After 7 years of trying to fully understand REST I'm still discovering
> nuances that are not clear, such as "the meaning of stateless."  If I were
> better at understanding abstract explanations[1] I would probably be much
> farther along but I'm just no good without a lot of relevant examples that
> illustrate the associated principles.
>
> To that end I'd like to ask about some examples?
>
>
> 1.) *Shopping cart:*  We have a web API that allows a user to add items
> and the server keeps track of the items in my shopping cart. For example a
> shopper would first add items to their shopping cart which behind the
> scenes would POST to a "new cart" resource, (B 1..n) POST to a "new item"
> resource for each item to be purchased, (C, D) PUT billing and shipping
> addresses to the cart, (E) PUT payment information and finally (F) PUT a
> "order-placed" value to the cart to place the order.
>
> 2.) *Batch Operations:* In "RESTful Web Services"[2] in the section[3]
> preceded a few pages by the section "Why Stateless Matters"[4] they
> recommend to use "Batch Operations" for transactions such as the
> archetypical "move funds between checking and savings accounts" example.
>  Specifically they suggest (A) POSTing to get an account transfer
> transaction ID, (B 1..n) PUTting the new balances to the different
> accounts, and then (C) PUTting to the account transfer transaction ID to
> complete the transaction. And they make no mention of this approach being
> stateful after just writing about statelessness.
>
> Are these examples stateless, or not? Are they RESTful, even if they use
> resources and hypermedia, et. al.?  If they are not RESTful then does that
> mean they are doing it wrong from a use-case perspective or that
> RESTfulness needs to be evaluated like other criteria, i.e. performance,
> ease of development, et. al?
>
> -Mike
> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm
> [2] First Edition, Richardson & Ruby
> [3] Page 230
> [4] Page 222
>
>  
>

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