Re: the meaning of stateless

Remember back in the days when they had manilla envelopes and mail guys in
companies?

As an example they were bringing you an employee handbook. It was in a
manilla envelope with a piece of paper for you to sign. You took out the
manual signed the paper then looked back at the envelope...

Your Name
Your Boss's Name
The HR Person
Legal

You would scratch off your name from the top of the list then put it to the
mail guy would bring it to your boss to sign. Your boss would sign it and
then scratch off their name and it would go to the HR person who would do
the same and finally it would go to legal. We could also designate error
handling through this process by either backtracking or designating a route
for error conditions.

This pattern is capable of both handling transactional and workflow type
behaviours and is known as a saga. It can easily be implemented over a
RESTful API.

Cheers,

Greg

On Thu, Apr 25, 2013 at 7:12 AM, Mike Schinkel <[email protected]> wrote:

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



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.