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).<p>HTTP basic auth does this automatically.<p>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.<p>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.<p>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).<p>Read my other comment for more information.