Target Audience

Developers who are new to website programming or who might like a review of stateless and stateful models of site design.
.

Introduction

The stateful and stateless models of software application behavior define how a user’s web browser communicates with a web server. In the earliest years of the Web, sites tended to be stateless. Pages were static, not varying from user to user. Later, websites included the stateful model, which delivered pages with information unique to each user. Stateful web applications are essential for modern e-commerce such as online retailers and banks, but require sophisticated programming to work effectively.
.

Stateless Model

In the pure form of the stateless model, a client program makes a request to an application server, which sends data back to the client. The server treats all client connections equally and saves no information from prior requests or sessions. A website that serves up a simple static web page is a good example of the stateless model. The server receives requests for pages it hosts and sends the page data to requesting browsers, much like a short-order cook making meals for diners.
.

Stateful Model

When an application operates in a stateful mode, the server keeps track of who users are and what they do from one screen to the next. Preserving the state of users’ actions is fundamental to having a meaningful, continuous session. It typically begins with a login with user ID and password, establishing a beginning state to the session. As a user navigates through the site, the state may change. The server maintains the state of the user’s information throughout the session until logout.
.

Getting States into Stateless

Many websites generate pages dynamically, relying less on static HTML files. The user’s browser receives page data from a web server and renders it as it would a static page. In addition, dynamic pages allow the server to “remember” the user and create continuity from page to page. To make continuity work, a developer can employ a number of tricks, adding stateful features to the stateless model. For example, when a user logs into a bank’s website, the server creates information about this session. The information may reside in the server’s memory, but it may also be stored in the browser. The server keeps track of your session by recording unique information about the session, such as a user’s IP address. In addition, the developer can create additional server-side variables used by the programs on the server. These variables remain intact as long as a session is active, vanishing upon logout or session expiration.
.

Browser-Side Data

A few different options exist for keeping session data in the browser. One is the cookie, a special type of browser token. A web server may create a cookie and store it in the user’s browser so that it can query it during the session. A browser stores these cookies and returns them upon server request. Cookies can optionally expire with the session or persist nearly permanently. If they remain, however, the data can be read by any site, potentially revealing information the user might not otherwise share. Many companies’ indiscriminate and unauthorized data-gathering from the use of cookies has led to a sense of distrust from many Internet users. Many users, in turn, have responded by setting their browsers to block cookies, making cookies less available for legitimate purposes.

In addition to cookies, you can communicate session data to a server by putting variables in the URL, set off with a question mark, such as in this example:

http://mysite.net/anypage.php?userID=54321&orderID=51926

Note that the very first variable is set off with a question mark and subsequent variables use an ampersand.

Many sites use URLs to pass data from client to server. One drawback is that the URL data is visible to anyone. It is possible in some instances to exploit URL data to obtain unauthorized information or otherwise subvert a site’s security. Also, a hacker who monitors your Internet traffic can intercept URL data easily. You can, however, obscure URL data by passing it in encrypted or hashed form, improving its security.
.

Server Load

When running websites that use the stateless mode, a cloud server has a job that is relatively easy, serving up pages without the need to save the user’s data. A stateful site has additional memory overhead for each user, needed to store basic session data plus user responses and other data required by the application. For sites that handle thousands of simultaneous sessions, the additional memory requirements add up. A stateless site that relies primarily on static pages is also easier on the server’s CPU. By contrast, a stateful site depends more heavily on dynamic, program-generated content, requiring much more CPU horsepower per session. A savvy operations staff keeps a close watch on server memory and CPU performance data, looking for bottlenecks that can affect a site’s responsiveness.
.

Conclusion

In the modern Internet, a completely stateless website is of limited use, since more and more content relies upon keeping track of data from a visitor’s session with that site. To create dynamic websites that “know” their customers, a web developer must keep in mind the differences between stateful and stateless modes and the benefits and drawbacks of each approach as pertains to the particular page or page element.
.
.