In the world of software development, APIs are everywhere, enabling different systems to interact seamlessly. But what exactly are APIs? Are they an internet thing? An API can be for anything e.g. a car has its own API, and even a human being has its own APIs. APIs are not just an internet thing; they are protocols and we have multiple types of APIs, most of which we see on the internet and are known as the REST APIs.

Understanding “State” in the Internet Context

A short introduction to “state,” especially in the internet context, is necessary. Generally, the state refers to the characteristics. Just as APIs can be for anything, states can also be for anything. For example, a car’s simple state could be whether it is in ignition or not, whether it is started, or if the handbrake is engaged. Additionally, if the car is turning and its wheels are angled, that represents another state. Similarly, there are some states in the client/server communication.

With a grasp on what state means, let us differentiate between stateful and stateless APIs, focusing on REST APIs’ stateless nature.

Statelessness in REST APIs

REST APIs themselves are stateless, but there are protocols out there where the state plays a significant role. One example of a stateful protocol is WebSockets. This discussion will briefly introduce what state is in WebSockets to build an understanding of what statelessness means.

Understanding State and Statelessness

State can include the user’s information, the user’s connectivity, or previous messages from the user. These are the most important aspects when playing an online game, for example. WebSockets are protocols that carry these states. Every time there is a WebSocket connection, there is some user information, a persistent connection, and some previous state maintained.

REST APIs are designed to be stateless, meaning there is no need to save any client context between requests. However, effective communication requires a certain source of truth, some form of state somewhere. For example, logging in. It is necessary to determine if a user is logged in or if the correct password was entered while trying to log in.

Even though REST APIs are stateless, it does not mean there is no memory or no state somewhere else. The server uses databases or other storages to hold data e.g. user credentials for logins. To illustrate how REST APIs handle user authentication without maintaining state, let us walk through the process of logging in.

To read examples of State and Statelessness, read the detailed version of this publication here.

Advantages of Statelessness

One advantage is saving internet bandwidth by maintaining a stateless architecture. Additionally, server resources are conserved and performance is improved. The server’s CPU load decreases because it does not need to maintain client-specific session states. It recognizes that each incoming request contains all the necessary information. Storage is saved, and server performance is enhanced by reducing CPU cycles.

Conversely, it is important to understand the potential challenges that arise if REST APIs were not stateless.

Potential Issues Without Statelessness
Large platforms like Amazon, YouTube, or Google Drive that handle millions and millions of requests per second from millions of users, if each of those requests required maintaining a state on the server, the amount of data storage needed would be astronomical.

To further illustrate the importance of statelessness, let us examine how scalability and resource management are handled in large-scale services.

Scalability and Resource Management

When algorithms predict user preferences, such as showing ads on Facebook based on activities, does Facebook store a detailed state for each user indicating their preferences? No.

While Facebook stores user data for personalization, it does not rely on server-side sessions to maintain states between requests. In this particular example, Facebook might send a Response Header to the user on login. This header serves as a Group Number assigned to the user. Several users can have the same group numbers justifying their similarity in interests. These group numbers relate a user irrespective of their identity, to their preferences.