Re: the meaning of stateless

On Apr 24, 2013, at 9:34 PM, Mark Baker <[email protected]> wrote:

Thanks for the reply. 

>> Okay, can you explain a broader view?  An approach this is not stateful?
> 
> Remember the days before electronic banking when we had to fill out
> slips and submit them to a teller?
> 
> POST /transfer-request
> {"from": "http://example.org/acct/12345",
> "to": "http://example.org/acct/12346",
> "amount": 300 }


Yes, of course. 

But you did what I was afraid of as I was writing my question; you took my example where I deliberately broke out into multiple requests to *illustrate* situations where state across requests is required and you changed it to be trivial which seems to imply there are no applicable use-cases that need multiple requests.  

The 2nd reason I chose that example is because it was effectively the same as the recommendation for "batch operations" that Richardson & Ruby used on page 230 of RESTful Web Services, First Edition which followed page 222 that explained why "stateless" is so important.  This implies either batch operations are not the same kind of state that Roy admonishes against, or that Richardson & Ruby where blissfully unaware of the irony of that recommendation juxtaposed with the discussion of the stateless requirement just 8 pages apart. And if the latter then I would ask it is even possible to create a RESTful system that has batch operations?

Anyway, let me take your example which I assume is RESTful and ask my question another way. It seems to me that if I started with a state of "500" in account "12345" and "0" in account "12346" and do your POST example I end up with "200" and "300" in the accounts, respectively.

However if I now do your POST example *again* it will fail, because I don't have enough money in the "from" account to complete the transaction.  So how are the account balances not "state" in the context of Roy's "stateless" requirement?

If you tell me the reality is that most non-trivial uses-cases for a web APIs actually need to be stateful in some ways and that the "stateless" requirement for REST is an ideal that has benefits when it can be achieved but is often impossible to realize then I think I'd be finally coming to an understanding of the stateless requirement.  :-)

But if you say "No, stateless can be achieved in most cases" then I'm even more lost than when I started asking questions on this thread a few days ago. :-(

-Mike