The communication between clients and servers must be stateless. Session state is kept entirely on the client, and the server knows nothing of it. The server is not expected to manage the state of the application. This allows the server to manage the resources while the client manages the application state. Statelessness promotes session independence. Because of session independence, any server can process the client request. This makes load balancing possible. Each request is standalone and must contain all the information necessary to perform the request, because it cannot rely on any context information.
With stateless systems, the state does not disappear. It just gets externalized into the clients and/or databases that the stateless app interacts with. In this respect, stateless apps require more sophisticated clients that cache their own state information, which provides the context for subsequent transactions. Now, stateless apps and their clients interact with greater independence. A stateless API can increase request overhead by handling large loads of incoming and outbound calls, a REST API should be designed to encourage the storage of cacheable data.
Important properties that are included by statelessness:
|– scalability: the server no longer needs to keep track of client sessions or resources between requests, and can quickly free resources after requests have been finished. Any server can handle any request: essential to modern cloud computing and the internet;|
|– reliability: it will also be easier for the client to recover from failures, as the session context on the server has not suddenly gotten corrupted or out of sync with the client;|
|– less complex: no server side synchronization logic and server never loses track ‘where’ the client is in the application;|
|– visibility: every request contains all context necessary to understand it. Therefore, looking at a single request is sufficient to visualize the interaction;|
|– efficiency: degrades efficiency: it increases network bandwidth since every information needs to be passed in every request;|
|Fielding’s thesis part||https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm|
|Matthias Biehl||https://restapilinks.com/wp-content/uploads/2021/02/api_architecture_biehl.pdf (p.49)|
|State-less-ful||Stateless vs stateful|