6

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.

koo
  • 4,013
  • 6
  • 15
  • 31

1 Answers1

4

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.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • Good explanation! Can you give me an example of " 'enrich' a request with context from previous requests."? I am almost there. – koo Apr 09 '19 at 10:32
  • Typical example is of course login information, like user name, rights or roles determined at a "login" request made previously. But can include things like: The business entity you are "currently" working on (current Customer you are serving, etc.), last queries executed, etc. – Robert Bräutigam Apr 09 '19 at 10:49
  • I have one more question if it is okay! How about in case of shopping-cart session? when the client puts an item into the shopping cart, server will save that information as session. But as you've said, it seems that the next request may not related to the previous context. Whatever the user stores won't influence to the next request. So it isn't violating REST statelessness. Hope I understood correctly! – koo Apr 09 '19 at 11:04
  • A shopping cart on the server *could* violate REST and statelessness if implemented that way. Usually however it is a business-related state held by the server, not a state of the communication between server and client, which would be ok. But, as I said, some things come down to interpretation. You could theoretically store the shopping cart on the client too, which would make the design less ambiguous. Both work, and both are compatible with REST and statelessness if done properly. – Robert Bräutigam Apr 09 '19 at 11:23
  • "could violate" make sense. It would also be important to be flexible only not to fix the implementation following REST. appreciate it. – koo Apr 09 '19 at 11:33