CODEWITHSUNDEEP
restservletsjax-rshttpsession
Cosigin
Cosigin

Reputation: 93

REST and HttpSession object

I know that REST is not supposed to use HttpSession. From the other side, the REST service is running within a servlet container. From what I saw, the HttpSession object will be created only when: 

HttpSession session = request.getSession();

code is executed. Is it always the case? Besides using JSP?


My question is: will be HttpSession objects be created when the REST method is executed or not?

Let's say I use the JAX-RS framework, if it can make any difference.
If such objects are not created, it actually can mean that the size of the server memory may not grow irrespective of how many clients use it the server.

Upvotes: 6

Views: 4381

Answers (2)

Archimedes Trajano
Archimedes Trajano

Reputation: 41672

I think this is the limitation of Java EE framework at the moment I haven't seen it done otherwise any other server yet. If you need to have a container managed security-constraint a session will be created.

That being said you do not require to implement your code to use container managed authentication. People do implement authentication login/mechanisms themselves like Shiro and what not.

If you're concerned about scalibility, you may have to handle the authentication on your own. However, before you continue with this path consider the following... how many people are you expecting to use your app? Unless you're some really big and popular service like Facebook or Google etc, present hardware/cloud offerings should be able to handle your load with HTTP Sessions with a lot of room to spare.

However, if you wanted to do it an implement yourself then I suggest the following:

  1. unauthenticated client passes credentials (via WWW-Authorization is the easiest to test with)
  2. credentials are validated and a token is returned. The token is an encoded encrypted string containing client ID, an expiration and a reauth token. This token is passed back to the client with Set-Cookie
  3. Client makes future requests with the Cookie containing the token
  4. The token can be used as long as it hasn't expired, this would just be crypto calculations on a server node and thus can be scaled across multiple servers if needed there's no single data store to deal with.
  5. The reauth token can be used to generate a new token for the client should it expire (this is useful for user applications where the interaction can last for minutes).

You can add an enterprise cache to store which ones are still valid at the expense of an extra backend call.

Upvotes: 0

Donal Fellows
Donal Fellows

Reputation: 137767

HTTP sessions are actually used quite often with REST interfaces, but should never contain anything truly critical. Thus, they can be used to contain the fact that you've authenticated or what your preferred default ordering of some list is; in the former case, you could also support other authentication mechanisms at the same time allowing fully stateless operation, and in the latter you can easily also support explicit overrides. So long as you don't require a session — well, under the assumption that your site was using HTTP BASIC auth for the sake of argument; if you're using OAuth then you need sessions enabled to stop performance from being crippled — then you're still potentially reasonably close to RESTful (in this area for sure; REST is not “don't use sessions” after all).

Is there a concern about how long a session lasts before timing out? Well, maybe but not really. A session is really an object that you've mapped into some database table, and you can configure the expiry policy on them so that they last long enough to support effective use without being over-burdensome. Which depends on how many clients use the site at once, what their usage patterns are, and what hardware resources you've got available (of course).

Upvotes: 3

Related Questions