Menu
This question crossed my mind after I read this post: “Common REST Mistakes: Sessions are irrelevant”
If sessions are indeed discouraged in a RESTful application. How would you handle licenses in such application. I'm specifically referring to concurrent licenses model and not named licenses. i.e. the customer buys X licenses which means the application may allow up to X users to be logged in simultaneously. Which means that the application must hold a state for current logged in users.
I know I can create a resource called licenses, which will set a cookie or generate a unique ID, and then the client will have to send it with every request. But it's the same as creating a session, right?
If I'll adopt the stateless approach and ask the client to create an authentication token for every request how will the application know when to consume and release license for that client?
Is there an alternative? specifically a more RESTful alternative?
938
RESTful API endpoints should always maintain a stateless session state, meaning everything about the session must be held at the client. Each request from the client must contain all the necessary information for the server to understand the request.
Each REST API call by a client is associated with a web service session. A session is created when client calls Login API and stays active until it times out or is logged out. When the session is created, a session ID that looks like a GUID is generated and assigned to it by the server.
For applications, a session is simply a way to track state across multiple interactions with the same client. While many modern applications are accessed using HTTP, the protocol itself is stateless. This means applications must implement some form of session management on their own.
Let me try to connect the dots for you, assuming I interpreted your question correctly. The link you posted has a valid answer, each request should use a HTTP auth. If you need the concept of licences to maintain a certain state for your user, you can most likely link that to the user. You have a (verified) username to go by. You just need to invoke that controller for each request and save its state. There you have your session.
Cookie input should never be trusted for any critical information, but can be very useful for extra verification like a security token. I think adding a random security token field to your on-site links would be the restful approach to that. It should expire with the 'session', of course.
67
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
