Does session stored in the databases really violate RESTfulness?

Question

I've read many many articles saying that sessions violate statelessness regards to REST.

If user logins the server, server gives session cookie(ssid) to the client, and stores the session data (user data) in the server, in this case memory.

It makes sense that it violates statelessness.

But how about session store in the database?

If user logins the server, server gives session cookie(ssid) to the client, and stores the session data in the mysql database, not in the memory.

Is this also violating statelessness?

If it is true, what is the difference between "session storing in the database" and "user request that is making query to database data?"

Both of them are extracting some data from the database when the client request is made.

It is obvious that the latter does not violate statelessness otherwise REST architecture would have never been that so popular.

my previous question, RESTfulness violation regards to the database the answerer says "it is not violating"

Vice versa, Do sessions really violate RESTfulness? the answerer says "yes it is violating". but that answer may bound to the only server-side(memory).

So confused.

Answer 1

Statelessness in REST specifically refers to the self-descriptiveness of messages.

That means each request must contain all the information necessary for the server to process the message. The request can not refer to previous requests for context. The linked document (Fielding's dissertation, the origin of REST) details quite well why that restriction is useful for distributed systems.

So in the end it does not matter whether something is in the database or in memory on the server, the client must not rely on previously established conversation state for followup requests.

Think of it this way: The client may delay its next requests for days, or the client may execute a request from some form of bookmarks, or the request may go to a different server than all previous requests. Or it may be the first request the client makes. This all should work exactly the same way.

Another important point is that "session state" is different from business-related things stored in the databases (that you seem to refer to). Of course the server may store business-related things in its database, it may even store or cache (in memory) login data or conversational state if it wants to, that's all fine. What the client and server may not do however is "enrich" a request with context from previous requests.

So the client may request to execute a query against some database, which obviously has some "state". What it may not do is to say: execute this query with additional parameters (like login) specified in some previous request I've made.

This line may blur in certain cases, for example when the server allows to create "transactions" for clients as resources. But when in doubt, always know why you need this property and what value you want to have from it in your specific architecture.