Re: the meaning of stateless

Fielding's definition of stateless is:

>
> "[C]ommunication must be stateless in nature ... such that each request
> from client to server must contain all of the information necessary to
> understand the request, and cannot take advantage of any stored context on
> the server."[1]
>
> This constraint is not about how resources state is changed on the server
> (clients send representations to the server) or how application state
> changed on the client (servers send representations to the client).
> Instead, this constraint is about the nature of the messages
> (representations via entity-bodies + metadata via headers) that are sent
> between client and server when changing each other's state.
>
> Each message stands alone and does not depend upon previous messages.
>
> <snip>
> Perhaps to clarify what is meant in REST by "stateless" someone could give
> examples of things that *aren't* "stateless", and contrast them to REST.
> </snip>
>
> HTTP servers that maintain persistent session state for each client during
> the life of the client-server interaction set are not stateless.
>
> FTP servers that allow clients to change directories relative to the
> results of a directory change in a previous request (cd ../..) are not
> stateless.
>
> Hopefully, this gives you some helpful ideas.
>
>
> [1]
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
>
>
>
> mca
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mikeamundsen
>
>
>
> On Sat, Apr 20, 2013 at 10:33 AM, Brian Craft <[email protected]>wrote:
>
>>
>>
>> I don't understand how the word "stateless" is being used in REST.
>> Obviously POST and PUT create state on the server. Obviously, requests
>> after a state change depend on that state change (e.g. by using a URL that
>> was not valid before the state change).
>>
>> I can almost live with this usage of "stateless" for persistent objects
>> stored on the server, because it can be thought of as not being "session
>> state": it lasts longer than a session. But in any moderately complex web
>> app, if you try to design a REST API you will quickly hit GET size limits
>> when doing complex queries. And then the suggestion is to do something like
>> POST the query parameters, returning a Location header for a "query" object
>> that can be fetched with GET. How is that not storing session data on the
>> server? How is that different from non-REST solutions?
>>
>> There are three obvious differences between POSTing a query and just
>> generically using POST instead of GET. POSTing a query requires two
>> round-trips to the server, bad for latency. POSTing a query and using a
>> Location header limits the response to the creation of a single object,
>> which is fine for 1990's full-page-load design, but is unrealistic for any
>> moderately complex ajax app, where an API call will result in the creation
>> of multiple objects (e.g. creating related images). And POSTing a query
>> requires the tracking of large numbers of transient "query" objects, hugely
>> complicating both client and server, the very thing REST is supposed to
>> avoid.
>>
>> Perhaps to clarify what is meant in REST by "stateless" someone could
>> give examples of things that *aren't* "stateless", and contrast them to
>> REST.
>>
>>
>> 
>
>
>