We talked about stateless in the REST architectural constraints section. Being stateless makes web services highly scalable. There is no affinity need to retain between the clients and the servers. Any server can process requests from the API clients.

Let's go back to the question of whether or not HTTP sessions should be used in RESTful APIs. If you're creating APIs for internal usage between the frontend and the backend of a monolithic application, HTTP sessions provide a straightforward implementation of the API authentication. You can even archive the scalability using load balancers with the sticky session feature enabled to route the requests of the same session to the same server. Also, you can use Spring Session with Redis to enable clustered sessions to archive high availability so that when the original server that the client interacted with is offline, other servers can pick up the requests from that client transparently. However, it is true that if there is overhead with the clustered sessions, Redis itself could become a single-point-of-failure. For public APIs, you should avoid using HTTP sessions to manage request authentication. Public APIs should be stateless.

For our TaskAgile application, we will use HTTP sessions for the internal APIs that won't be stateless. For future versions of the application, we will create stateless public APIs.