> When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server.
Distributed key-value stores have been a thing for ages. Besides, the information you are accessing and manipulating through that REST API is probably stored in some sort of database, so you most likely already have a straightforward way to share state among your frontend servers. It's only a matter of whether it's fast enough for your purpose.
Most people don't even have to go "distributed" on the backend. A single Redis instance can handle upwards of 1 billion requests per day.
You are making my argument. You are saying there is no need for session state on frontend servers. That's my argument as well. And there's nothing wrong with JWT that prevents it from being used to identify the user or the associated backend data.
I think you are misunderstanding the statelessness of REST. Each HTTP request is stateless in the sense that it can be understood without having previous HTTP requests around. But you can build sessions on top of that (= into your application) and that is not "against the rules".
Also, with regarding to REST "front-end servers" aren't part of the discussion, but an implementation detail.
Distributed key-value stores have been a thing for ages. Besides, the information you are accessing and manipulating through that REST API is probably stored in some sort of database, so you most likely already have a straightforward way to share state among your frontend servers. It's only a matter of whether it's fast enough for your purpose.
Most people don't even have to go "distributed" on the backend. A single Redis instance can handle upwards of 1 billion requests per day.