We are building a set of web APIs. The web APIs are called by clients & can call each other.

State is required by these APIs for the users session (e.g. shopping basket type stuff). The state can be large (over 8k) so doesn't look appropriate for the client.

At the moment the state is being managed directly by the application code interacting with a database to store & retrieve the session state. A housekeeping job clears the database daily. HTTPSession is not used.

We are considering a move to session affinity to reduce database IO. We would still write incase of node failure but it removes the need to read.

If we move to session affinity am I correct in saying it would make sense to use HTTPSession for our in memory session state so that the web container can manage the lifecycle?

  • The way you capitalise HTTPSession makes it seem like you have a particular technology (programming language / framework / library) in mind, but you don't mention any. Could you clarify?
    – IMSoP
    Oct 18, 2020 at 12:11
  • We use Spring & Tomcat, but only for the REST framework at the moment. All state management is by direct IO from app code to database.
    – Bryn Davis
    Oct 18, 2020 at 12:25
  • For what it is worth - REST is stateless. "Session state is therefore kept entirely on the client." See ics.uci.edu/~fielding/pubs/dissertation/… Oct 18, 2020 at 12:26
  • Thanks for the link. Everyone seems to have their own view of what "stateless" means. Many of my colleagues see stateless as "not in process memory". I tend to think as stateless as state on the client only. But I am where I am & I have to work within the constraints I am given.
    – Bryn Davis
    Oct 18, 2020 at 12:55
  • Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. source: restfulapi.net I think you should edit your question, because your HTTP Api is clearly not a RESTful Api. Calling it that confuses people and takes away the focus from the real question.
    – Rik D
    Oct 18, 2020 at 13:07

1 Answer 1


When people talk about a "stateless API", they don't mean that requests can't have any effect on the state of the server - the "S" in "REST" stands for "state", after all - but that the meaning of a request doesn't change based on state. This is achieved by making each stateful object an explicit part of the API.

So, a stateful API might have a verb "add item to my shopping basket", with a meaning entirely dependent on matching the request to a previous "create basket" request. In a stateless API, you might instead say "add item to basket 42", with the identifier "42" having been remembered by the client from the "create basket" response.

REST takes this further, and says that the objects should be the central concept, rather than actions with side-effects on those objects. So GET /basket/42 might return the current contents of that basket, POST /basket/42/items might add a product to it, and DELETE /basket/42/items/13 remove a product.

The reason this is useful is that it gives the client more flexibility in how to use the API, and the API more flexibility in the features it offers. For instance, a client might want to maintain two separate baskets, but based on one set of search results; or the API might offer the ability to clone a basket, or merge two baskets to pay for them at once.

So rather than moving further towards using a transparent "session" handled by the server software, I suggest you start thinking about what stateful objects each service's session identifier represents.

Even if you don't redesign the services to make those objects explicit, you can reframe your architectural decisions:

  • What is the appropriate lifetime for this object?
  • How often is this object read vs written?
  • What would be the consequences if this object was lost due to a server failure?
  • Do you need central observability of this object?

All of these need asking anyway if you use HTTPSession, since you need to configure where it stores its data, how long it stores it for, and so on. The main thing that would automate is the least relevant for an API: how to make a stateless web browser act like a stateful client without custom client code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.