Rest Concepts: Should the system authenticate every request of a session

Question

Started working on a new project, which claims it has RESTful Api. One common pattern I am seeing is that none of the incoming is being authenticated. Wherever required, session object has been used to get user information.
When I talked to the responsible person, he told me that it is very expensive to create a user session for each request. The idea behind this implementation was that sending a request to database to authenticate the user.It is time-consuming and unnecessary when session object is already there.
I could not say anything more than it is not stateless implementation and it is against the REST philosophy.

What are the other practical reasons to not to use this type of design implementation?

Answer 1

A don´t think there is anything wrong about the design you described, it is actually very common in the age of single page applications.

But to answer your question, one big reason to why REST has been defined as stateless is scalability. When you use server session to store authentication information, or any king of server related storage, you must maintain it across another nodes in clustered environment. If you have 2+ nodes, they must either share or replicate auth storage (usually session), or enforce that one user communicates with the same node, which is called sticky session. Or you can combine both techniques so you can shut down one node without affecting users using it.

Obviously, you don´t need this when you have truly stateless API. From my point of view, it is OK to use statefull auth for SPA backend and stateless auth for standalone web services. But there is no straight line there.

Answer 2

The statelessness of REST does not mean that the server cannot store state. Most services have lots of state stored in a database. And there is nothing wrong with using something else than a database, like a distributed in-memory cache which most session storages are.

What statelessness does mean is that the client shouldn't assume that the server remembers information about previous communications. Every request should contain all the information needed to deduce its meaning.

A classic example is an FTP server, which accepts commands like "cd somedir". All succeeding operations are then assumed to occur in this directory. This is not stateless in the RESTful sense, since the meaning of the succeeding messages are dependent on this previous one. This can easily be fixed by letting every command include its current working directory.

Now if you look at your case, you are sending a session identifier with every request, which is used to lookup authentication information. And since this information is passed in every request, you can actually consider the construct stateless in a RESTful sense.

Answer 3

Sure, it's against the REST architectural style. The real questions are if either of you understand why, if the responsible person made an educated determination that the tradeoff was worthwhile, and whether you agree or disagree. That's the basis for the conversation you two should be having.

Personally, I might suggest that sticking the auth data in a database cache and maintaining statelessness is a better approach for ensuring current performance and future scalability, but of course I don't know anything about the system.