title: Stateless web application, an urban legend?
body: <p>I am trying to understand <code>token-based authentication</code> these days, which claims to be a <code>stateless authentication</code> method. And I met the concept of <code>stateless web application</code>.</p>
  
  <p>Below are some threads I read about:</p>
  
  <ul>
  <li><a href="https://stackoverflow.com/questions/20433261/use-spring-mvc-for-stateless-web-application-development">Use Spring MVC for Stateless web application development</a>  (no response yet)</li>
  <li><a href="https://stackoverflow.com/questions/8694427/stateless-spring-mvc">Stateless Spring MVC</a></li>
  <li><a href="https://stackoverflow.com/questions/26830248/how-to-make-a-java-web-application-fully-stateless">How to make a java web application fully stateless</a></li>
  <li><a href="https://stackoverflow.com/questions/3016326/how-do-i-make-my-web-application-stateless-yet-still-do-somthing-useful">How do I make my Web Application stateless yet still do something useful?</a></li>
  </ul>
  
  <p>At first, I was thrilled at this idea. But more and more I think <code>stateless</code> is a <code>pseudo-proposition</code>.</p>
  
  <p>For example, suppose we use client-stored token for authentication, how can we make a statistic of online users (suppose there's no log)? Shall we store the token in DB? Doesn't that mean we store state info on server? And even more, is the plain user info such as name, age, etc. in DB also some kind of state info?</p>
  
  <p>I think the real question here is not to make a web app stateless, but <strong>to make the web app properly handle the state info such that it won't jeopardize scalability</strong>.</p>
  
  <p>That depends on how to interpret the word <code>stateless</code>:</p>
  
  <ol>
  <li>Web app doesn't have state.</li>
  <li>Or web app doesn't store state <em>itself</em>.</li>
  </ol>
  
  <p>I prefer 2 because there can always be some <code>inevitable global state</code> (quoted from @deceze's comment to his answer). And no matter we store state info as HTML 5 web storage, or HTTP header, or hidden form fields, or Cookie, the state still exists. Only that it is stored somewhere other than on the server.</p>
  
  <p>Am I missing something great? Could anybody shed some light on this so I can be relieved from this mental struggle?</p>
  
  <p><strong>ADD 1</strong></p>
  
  <p>Just read about the book <a href="https://rads.stackoverflow.com/amzn/click/com/0596529260" rel="noreferrer" rel="nofollow noreferrer">RESTful Web Services</a> by <code>Leonard Richardson</code>. In chapter 4, at end of the section <code>Statelessness</code>, it classifies the state into <code>Application State</code> and <code>Resource State</code>. So the plain user info and data I mentioned before like images, etc. can be classified as <code>Resource State</code>. And what <code>stateless</code> refers to is <code>Application State</code>. So it doesn't break the code of stateless to store <code>resource state</code> on server.</p>
  
  <p>But the book also mentions the scenario where <code>an application key is used to restrict how many times a user can invoke a web service.</code> It admits that such info cannot be stored on client side. And having to store it on server side breaks the code of stateless and introduce the issue of session affinity. <strong>It claims stateless can avoid session affinity issue but doesn't explain how.</strong> <strong>I really don't see how stateless can handle this scenario. Anyone could shed some light here?</strong></p>