Statelessness

The concept is very easy to understand. In a server/client architecture, the server needs to know which client is requesting data from it and, accordingly, it decides what to send and what not to send.

However, REST systems are stateless. That means the server does not need to know anything about the client's state and vice versa. That would eventually remove the overhead on the server to identify the client each time a request comes in.

But now the question is, how do the client and server interact? The answer is through appropriate messages. Suppose a user wants to see one order detail. It would simply ask the server by sending the ID of the order and the server would return the order details in either .json or .xml format, which can be easily parsed by the client. Every message has the required information for how to deal with that. 

These constraints (along with a few other constraints such as caching, layered system, uniform interface, and code on demand) when implemented on a web service help RESTful applications achieve reliability, optimized performance, and scalability. The reason being that components can be managed independently, updated flawlessly, and reused without affecting the system as a whole.

Let's look at exactly how communication takes place between the server and client in the next section.