Re: the meaning of stateless

On Apr 23, 2013, at 1:33 PM, Mike Kelly <[email protected]> wrote:
> if the client posts to a /query endpoint and then makes a get to a generic /result endpoint then the state (or context) is implicitly carried over and therefore there is no visibility in the second request. I.e there is shared state and the constraint is violated.
> 
That's very helpful. 

But may I ask for how that shared state might be implemented in an API?  I understand how it is implemented on the web where people login and surf, and I can guess at how it might be implemented for an API but it would be instructive if you could give some explicit examples of implementations to avoid.  HTTP headers containing context?

Would it be accurate to say that "requests need to be context-free" or even "requests should not depend on HTTP headers for resource identification"  than "stateless" considering the overloaded use of state? When one considers that a client can change server state and future client requests to the service will cause different behaviors based on what the requests the client previously made, that muddies the waters of of the use of the term "stateless", no?

-Mike