Does ST(State Transfer) in REST mean that state must be held by client?

Question

I read What does “state transfer” in Representational State Transfer (REST) refer to? and several post or videos about REST, and I know one of the constraint of REST is stateless.

1. According to many posts like http://www.restapitutorial.com/lessons/whatisrest.html ,to make the architecture stateless, the client must hold the enough information for the server to do the right thing, which means the server does not have any client state. So does it mean we are only about to build a REST application only through putting some user state in the client like cookie?

2. But according to many posts like Pros and Cons of Sticky Session / Session Affinity load blancing strategy? , we can make a stateless application by storing the user data in database or memcache, which avoid storing session in the application server. If we try this approach, can we make a REST architecture?

Abie

Answer 1

The idea of honest REST service is to allow easy communication with it to any client, even to the client that is not in a web browser: it could be mobile or desktop application or anything else. So, each request to the service must provide all necessary information to process that request. Keeping the state on server would complicate the task, because clients will not control it.

So, YES, ideally state must be held by clients. BUT, we need to understand clearly what we mean by "state". Because there are different kinds of state out there: Application state, and Resource state. I like the following article about the distinction.

P.S. And BTW, keeping state in cookies would complicate life to clients as well(if they are not web-browsers).

Tejeda

Answer 2

So does it mean we are only about to build a REST application only through putting some user state in the client like cookie?

You don't have to use a permanent storage to do that. If we are talking about browser terms, you can use a javascript program as a client, and you can store the application state (client state) in javascript variables instead of using a server side session and a session cookie.

If your system supports authentication, then you have to send the user identifiers (e.g. username and password) with every request for example in a HTTP auth header. Be aware that REST is mostly for automated clients, not for browsers, but ofc. you can write an automated javascript client for a browser as well.

we can make a stateless application by storing the user data in database or memcache, which avoid storing session in the application server

This is false.

Calcaneus

For stateless application, so storing session info in memcache is not considered as stateless? But I really see many posts about this :#26846068 , AND #26830748 – Abie

@Jaskey As long as you store session info on server side, it is not stateless. It does not matter that you user memcache or database... You should not rely on stackoverflow on this. Most people know nothing about REST here... Read the relevant section of the Fielding dissertation, that's what defines REST constraints, not some random people on stackoverflow... – Calcaneus