Is ST (State Transfer) in REST supposed that the state should be held by the client?

Question

I read What does “state transfer” mean in the State State Transfer (REST) ​​view and a few posts or videos about REST, and I know one of the limitations of REST is stateless.

• According to many posts, such as http://www.restapitutorial.com/lessons/whatisrest.html , to make the architecture idle, the client must contain enough information for the server to work properly, which means the server does not have client status. So does this mean that we are only going to create a REST application only by placing some user state on the client, such as a cookie?

• But, according to many reports, for example, “Pros and Cons of the Affinity Session / Session Adherence Strategy”, we can create a stateless application by saving the data user in the database or memcache, which avoids saving the session to the application server. If we try this approach, can we create a REST architecture?

Answer 1

The idea of ​​an honest REST service is to allow any client to easily communicate with him, even a client who is not in a web browser: it can be a mobile or desktop application or something else. Thus, each service request must provide all the necessary information to process this request. Saving state on the server complicates the task because clients will not control it.

So, YES, ideally, the state should be kept by customers. BUT, we need to clearly understand what we mean by "state." Because there are different types of state: application state and resource state. I like the following article about the difference.

PS And BTW, saving state in cookies, will also make life difficult for customers (if they are not web browsers).

Answer 2

Does this mean that we are going to build a REST application only by putting some user state in the client as a cookie?

You do not need to use persistent storage for this. If we are talking about browser terms, you can use the javascript program as a client, and you can save the application state (client state) in javascript variables instead of using a server side session and session cookie.

If your system supports authentication, you need to send user IDs (for example, username and password) with each request, for example, in the HTTP header of the HTTP header. Remember that REST is mainly for automated clients, not for browsers, but ofc. you can write an automated javascript client for the browser.

we can create a stateless application by storing user data in databases or memcache, which do not allow storing a session in the Server application

This is not true.