Stateless

The next constraint to add is stateless. The server should not contain any state of workflow. In this way, the client is the driver of the information that it wants. When the client asks the server for data, the client needs to pass all the relevant information to the server. This method of designing software creates an abstraction, where the server is unaware of the client; it creates a loose couple design, which is conducive to changes. Later on in the chapter, we will look further into stateless by expanding the idempotent concept.

The client has to keep track of its state. The downside is that the client will have to send more data to the server on each request.

Having the stateless server allows you to scale out, since the server does not store any client-specific data.