Re: the meaning of stateless

Hiya,

Mike Schinkel <[email protected]> wrote:
> 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. :-(

The state in question is really about how atomic the request is supposed to
be, and that it's not to rely on any other state not included in the
request. The typical example is doing a request that relies on information
stored in a session, for example.

Here's the simplest way to think about it; all that you need, you bring
with you. If the workflow is 10 steps, bring with you all 10 steps, and
mark them accordingly. The state of the workflow is all of them together,
and to change that state, you request them as a group, change the bits you
need to change, and put/post them all back.

Obviously, most people don't do this, even though it's the most RESTful
way, but this is why the manilla envelope is used; you bring the whole
thing with you, tick off your part of the 'workflow', and pass it on. This
way we make sure the state of the manilla envelope is correct. This
guarantees that state is transferred correctly. Yeah, there's the price of
the payload, but I haven't seen an example yet where that is an *actual*
problem rather than possible.

Hope that makes it a bit clearer for you.

Regards,

Alex
--
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---