Re: the meaning of stateless

Storing session information isn't negotiable, and is orthogonal to API
design. For example, no one sits down to design an API and says "Oh, a
restful API is stateless, so I can't use HTTPS, because it stores session
state on the server." The API design occurs independent of the statefulness
of the communication, which is dictated  by security concerns.  And the API
can be redeployed without change to HTTP, so the statefulness had no
bearing on it.

The FTP example is more enlightening.  It's only slightly different than
the "query by POST" technique that is said to be RESTful. The main
difference is that in "query by POST" an id for the query is returned by
the server. So in the FTP example, if the server returned an id for the
target directory of a "cd", and future requests referenced this id, would
it then be "stateless" and "RESTful"? And if so, how does that jibe with
the claims in the dissertation that statelessness means "session state is
kept entirely on the client", and "Scalability is improved because not
having to store state between requests allows the server component to
quickly free resources and further simplifies implementation." The server
does, in fact,  store and manage resources for the session.


On Sat, Apr 20, 2013 at 4:51 PM, mca <[email protected]> wrote:

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