[machuidel]

Actually, they are all valid ways when using the ReST philosophy. The idea is that with every request from the client the latest state is sent along with it (if needed). This way the state of the request can be reconstructed on the server without depending on centralized storage or a single server. The server may update the state and return it for the client to store again (some parts encrypted if needed). No need for the server to keep the state (this way it can remain stateless).

HTTP basic auth does this automatically.

Creating a resource for a session is optional but may be useful if the state to sent back and forth is too big. But this will require centralized storage.

The state may be stored inside a cookie where parts of it can be encrypted. It is also possible to specify that parts can only be updated by the server.

You may also use Local Storage and send the data across using an XMLHttpRequest or even use a HTML form (which may have limited support for the HTTP verbs).

Read my other comment for more information.

[sopooneo]

But it seems to me that ReST does dictate, specifically, that there must be no need for shared state. The system must work without the client having knowledge of the server and vice versa. But a cookie, as used to hold a session token which references information on the server, is very much shared state. So should be forbidden.

[machuidel]

The state is passed back and forth. The server does not keep the state (that is why they call it stateless), the client may keep it. If something does need to be stored on the server a resource should be created. The state that is passed back and forth may then contain a reference to the resource, a resource identifier (in case of the web usually a URI is being used).

The server is stateless because it receives the latest state from the client (location, cookie and other headers) and sends an new updated state (location, set-cookie and other headers) to the client again along with an optional representation. There is no need for the server to keep the state in memory anymore. Because the server does not keep the state it does not matter which copy of the server (in case of load-balancing or fail-over etc.) handles the next request as everything needed can be derived from the state sent along with request from the client.

Keep in mind that it is best practice to be able to reproduce a representation by the use of a resource identifier, like with "pure functions" in functional programming, it should be deterministic. The content of a representation may change but not the semantics of it.

The part that is stateful is the state that is being passed back and forth between the client and the server.

Does that answer your question?