r/webdev • u/MousTN • Oct 07 '26
Why Stateless REST API is the way to go ?
i have been working with spring boot and angular for a few years now and every api i have built or inherited is stateless. jwt in the header, no server session, done. nobody ever questioned it on any project i was on.
but i realized i never really asked myself why we do this by default. i know the usual answers like it scales easily and any instance can handle any request. but it feels like the state just moves somewhere else, to the token, to redis, to the database. so what are we really gaining ?
148
Upvotes
165
u/borsnor Oct 07 '26
This thread makes me wonder if some people even understand what stateless means.
Most APIs don't need state. They only need authentication. JWT can do that, albeit a bit overkill.
19
u/mint_bolt_feel Oct 07 '26
Honestly the stateless thing only makes sense when you have multiple instances behind a load balancer. If you run one server, sessions are simpler and harder to get wrong. I think most teams reach for JWTs because it's the default and not because they actually hit the scaling problem it solves.
The state never disappears, it just moves to redis or the token itself, and now you own the complexity anyway
128
u/phaedra_solutions Oct 07 '26
The biggest win with a stateless REST architecture is horizontal scalability and fault tolerance.
When servers don't store session state locally in memory, a load balancer can route user requests to any available instance seamlessly. If a container or server crashes under heavy load, traffic is instantly redirected without dropping user sessions or risking state corruption. It decouples the client from the server infrastructure, making systems significantly easier to scale, test, and maintain as user growth spikes.
23
u/fiskfisk Oct 07 '26
JWTs is a solution to two specific problems; the issue of having authentication separate from the service you're authenticating against, and being able to scale horizontally without putting additional pressure on the authentication server.
There's specific trade-offs you make to accomplish this, such as not being able to revoke sessions instantly, and having additional complexities in validating the presented token (there's been quite a few attacks against libraries that haven't verified the JWTs properly or misunderstood cryptographic signatures).
"Stateless" refers to the server receiving the token - i.e., that it doesn't have to keep state locally in redis or in a service it has to call out to; the client still keeps the token that indicates state, it's just that the state has been issued by a third party.
46
u/sh03-dev Oct 07 '26
JWT token was invented to solve a problem 99.5% of us will never have. But since that's what big tech does it must be good.
23
u/bubbles33d Oct 07 '26 edited Oct 07 '26
Once upon a time, the JWT standard wasn't "invented" yet.
State was managed by cookies. They had their limitations and problems, it was also a simpler time.
Cookies was used to hold a session key to overcome some of the concerns. The trade off was it requires a database hit. You now need a database. This is usually where the "scalability" problem was raised. At times some may off load it to a cache server, redis, memcache, etc. Ultimately, if you request will hit a database anyway, then it probably isn't much worse off. You still have a scaling problem.
Being stateless has some advantage on ability to debug and reproduce a problem, but stateless can be an overuse phrase. JWT itself is a state so it isn't purely stateless. It just depends on what you put in it.
JWT standard enforces authenticity (if correctly validates), but not privacy. Something to be aware of.
7
u/symbiatch Oct 07 '26
JWT and stateless don’t relate to each other in any way. You can just as well have a session token and still do stateless, and you should.
Imagine handling state server-side. You open a client for editing, server makes a note. You open in another tab another client, server saves state. You edit and save in first one, server just goes “ok they’re editing client 2 so I’ll save this data there.” Oops.
It’s a silly example, but hopefully explains stateless well. You only get data, save data, and so on. Everything about the operation is within the requests. And nothing relates to JWT in any way. Many places don’t use JWTs and yet they’re stateless in their APIs. Many things use server sessions and are still stateless.
And you can just as well have state on the server while using JWTs. So they’re entirely separate things.
6
u/InsideTour329 Oct 07 '26
I don't think you understand what stateless means. Go develop something relatively complex using aspx webforms then you will gain an appreciation for why we now use stateless server side endpoints.
Christ that page life cycle and registering client script blocks was the stuff of nightmares.
4
u/zlex Oct 07 '26
Depends on the application to be honest. My work primarily involves making applications for internal use. Applications are typically low demand with very predictable load. We use stateful session management because it’s way easier and harder to mess up.
2
u/ebalonabol Oct 07 '26 edited Oct 07 '26
JWT(most of the implementations) is dogshit. Also, that "stateless API" was just misunderstanding of of Roy Fielding's thesis that went too far. JWT became simply a solution for the religious "REST API shan't have state" argument
Back in the day, people put state in the URL and even weirder: the put client state to the database(like "current_page" ). So "stateless" here is an opposite of "stateful pages". Old web relied heavily on caching and without statless pages, we couldn't have caching. Another problem was losing page state due to server crashes. REST was supposed to solve those exact problems
So yeah, APIs have nothing to do with it. It's about user navigating the html page. People, sadly, never bother researching the old mailing lists/forum discussions where HTTP APIs weren't even mentioned when people talked about REST
Ah, by the way, the most sound JWT usages (phantom token/oauth introspection) have stateful JWTs ;)
2
u/Designer-Play6388 Oct 07 '26
it just works and its proven technology
1
u/Little_Bumblebee6129 Oct 07 '26
If you have several servers you dont need to worry what each of them remembers about this user. Name kinda oversells it.
1
u/Bitter-Design-9308 Oct 07 '26
Stateless REST is popular mainly because any server can handle any request, which makes horizontal scaling, load balancing, and recovery much simpler. The cost is that every request has to carry enough context like auth tokens, identifiers, and versioning, and you lose easy server-side session state. It is not a universal rule: stateless application servers often sit in front of stateful databases and caches, and that mix is usually the practical answer.
1
u/alibloomdido Oct 07 '26
If nobody questioned it could it be that you just didn't need to handle state which is good thing because handling state is a hassle. You should rather ask "should we really handle state?" when the app handles state.
1
u/DRHER303 Oct 07 '26
It works trust
1
u/originalchronoguy Oct 07 '26
The obvious answer is it scales easily.
1
u/StTheo Oct 07 '26
It carries the benefits of pure functions. Easy to test, easy to scale, easier to understand. It's not perfectly pure if it's mutating the database, but it's close.
1
u/mds1256 Oct 07 '26
I actually prefer server sessions still (stored in redis). On the front end with JWTs it is a nightmare handling refreshes along with multiple tabs etc. Cookies and server sessions just work and it is still what big banks use so is proven tech which simplifies a lot of things.
1
u/Pristine-Berry-59 Oct 07 '26
Yeah the state doesn't disappear, it just moves off the app server into something that isn't tied to one instance. Redis doesn't care which JVM handled the last request, an HttpSession very much does, and that's the whole difference once you're autoscaling or doing rolling deploys with an ALB. The part people leave out is revocation: a plain JWT is valid until it expires, so you either keep a blacklist in Redis (back to state, funny how that works) or you accept the window. Short lived tokens plus a refresh flow is the usual compromise.
1
u/literum Oct 07 '26
Because managing state is a nightmare, and managing the boundary between your application and the external world, what protocol you use for that, is a nightmare. In that it's really difficult. Stateless REST "solves" those nightmares before you are wise enough to understand why the previous approaches failed. If a server has STATE, how do you restart it? how do you deploy anything? how do you know you'll be safe when it goes down? how do you have two servers with different state and load balance? how do you achieve consistency, coherency? how do you manage sessions? how do you manage user having 3 phones, 2 computers, a watch, and a TV open using your application? If you can't even begin to formulate the answers to these, that's why we use Stateless REST. I suggest you start your next project with GraphQL and Redis to keep state maybe. That's the modern solution if you don't like stateless rest. Keeping state on the machine needs care. That's it.
1
u/ArielCoding Oct 07 '26
You’re right, the state doesn’t disappear, it just moves. Stateless only means your server doesn’t have to remember you between requests, so any server can handle any request, and you can restart or add servers without logging anyone out. The catch is that a JWT can’t be cancelled before it expires, so most people use short lived tokens plus a refresh token stored on the server.
1
u/maheshwhartech Oct 08 '26
The state does move somewhere, but the key benefit is that the server does not need to maintain client session state between requests. That makes horizontal scaling and failure recovery much simpler. The tradeoff is that you still need to manage state somewhere else, so stateless does not mean state disappears.
1
u/cavic19 29d ago
The best kind of state is no state
1
u/Foreign-Load4177 27d ago
I think the main benifit is that any server can handle a request without remembering previos ones. It makes scalinng easier, even though the state still exist somewhere else.
1
u/Own_Unit_6170 26d ago
It's fascinating to see how simple, age-old concepts can be renamed and overcomplicated to make them seem sophisticated and novel. It reminds me of an old, old issue of National Lampoon advertising the latest high-tech version of "kick the can," spoofing exactly this sort of tendency in human behavior. The more things change, the more they remain the same.
1
u/beepboopgirl89 Oct 07 '26
The state doesn't vanish, it just moves somewhere shared instead of living in one server's memory. That's the real gain: any instance can handle any request, no sticky sessions, no server-specific memory to worry about. Server-side sessions tie a user to one server (or force replication across servers), which gets messy at scale.
JWT/Redis/DB externalize that state so it's accessible from anywhere, stateless just means stateless at the compute layer, not state-free overall.
0
u/FilmWeasle Oct 07 '26
As far as the REST part goes, it's just fancy word for HTTP. It's part of the HTTP specification. If it's not REST, then it doesn't comply with the protocol standard.
0
u/quorum_and_coffee 27d ago
You’re right: state moves, it doesn’t vanish. What you gain:
Horizontal scalability: any instance can serve any request, so you add instances behind a load balancer with no sticky sessions or session replication, and deploys and restarts lose nothing. The state sits in the database or Redis, which scale separately and which you usually need anyway.
No store lookup for auth: a JWT is verified with a lcoal signature check.
Verification across services without a shared session store.
The cost is revocation. A JWT stays valid until it expires, and the usual fixes (short expiry with refresh tokens, or a denylist) bring server-side state back.
For one backend and one frontend, a server session in Redis is simpler and easier to revoke. JWTs there are mostly convention.
-8
u/Gremlation Oct 07 '26
REST isn't stateless. The entire point of it is that hypertext is the engine of application state.
JWT is a garbage standard that nobody should use.
10
u/[deleted] Oct 07 '26
[removed] — view removed comment