Licenses and sessions the RESTful way

Question

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?

Answer 1

If your licensing is based on concurrent users, implementing HTTP digest is trivial, and will let you enable only the maximum number of concurrent logins. Digest has provision for passing expiration data so your session can be timed-out.

Authentication state is hold by http authetnication and nowhere else, beause it is transparent and ubiquituous.

Answer 2

You may want to consider pushing the license handling concerns down the infrastructure stack one level. Sort of like an Aspect Oriented Programming (AOP) approach if you will. Instead of handling it in the application tier, perhaps, you can push it in to the web server tier.

Without knowing the details of your infrastructure, it is hard to give a specific recommendation. Using the *nix platform as an example, the license handling logic can be implemented as a module for Apache HTTP server.

This approach promotes a separation of concerns across your infrastructure stack. It allows each layer to focus on what it is meant to. The application layer does not need to worry about licensing at all, allowing it to focus strictly on content, which in turn keeps the URL's clean and "RESTful".

Answer 3

Maybe a more RESTful way of doing licenses would be to limit the rate at which requests are handled, rather than the number of concurrent sessions. Keep track of the number of requests in the last hour, and if it exceeds the number the customer has paid for, serve a 503 Service Unavailable response, along with some text suggesting the user try again later.

Answer 4

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.