4 ms·
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 JW
by flowerlad 5y ago
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.
- kreetx 5y agoI 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.
- flowerlad 5y agoI am sorry, I don't agree with your interpretation. My interpretation is aligned with this: https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest-server-api https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest... "...but creates no load and consumes no per-client storage on the set of servers or on the network" So no, per-client session state would be against the principles of REST in my view.
- flowerlad 5y agoThis might help you: https://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions/34700703 https://stackoverflow.com/questions/3105296/if-rest-applicat...