title: Can REST in practice really be stateless?
body: <p>Consider the situation.</p>
  
  <p>I am writing a statistical analysis app. The app has multiple tiers.</p>
  
  <ol>
  <li>Frontend UI written for multiple device types, desktop, browser,
  mobile.</li>
  <li>Mid-tier servlet that offers a so-called REST service to
  these frontend.</li>
  <li>Backend that performs the extreme computation of the statistical
  processing.</li>
  <li>Which communicates with a further backend database</li>
  </ol>
  
  <p>Due to the reason that statistical analysis requires huge amount of processing power, you would never dream of delegating such processing to the front-end.</p>
  
  <ol>
  <li><p>The statistical analyses consists of procedures or a series of
  work-flow steps.</p></li>
  <li><p>Some steps may require so much processing power, you would not want
  to repeat them.</p></li>
  <li><p>If you have a work-flow of 20 steps, you cannot execute step 20
  without first executing step 19, which cannot be executed without
  first executing step 18, so on and so forth.</p></li>
  <li><p>There are observation points, such that, for example, the
  statistician must inspect results of steps 3, 7, 9, 14, 19 before
  telling to client-side to proceed to the next step.</p></li>
  <li><p>Each of these steps are a so-called request to the REST service, to
  tell the backend supercomputer to progressively set up the
  statistical model in memory.</p></li>
  <li><p>There are many workflows. Some workflows may incidentally share step
  results. e.g., Flow[dry]:Step[7] may share Flow[wet]:Step[10]. Due
  to the amount of processing involved, we absolutely have prevent
  repeating a step that might incidentally have already be
  accomplished by another flow.</p></li>
  </ol>
  
  <p>Therefore, you can see that in the so-called REST service being designed, 
  it is not possible that each request be independent of any previous request.</p>
  
  <p>Therefore, how true can the following statement be?</p>
  
  <blockquote>
    <p>All REST interactions are stateless. That is, each request contains
    all of the information necessary for a connector to understand the
    request, independent of any requests that may have preceded it.</p>
  </blockquote>
  
  <p>Obviously, the application I described, requires that request be dependent on previous request. There are three possibilities that I can see concerning this app.</p>
  
  <ul>
  <li>My app does not comply to REST, since it cannot comply to stateless requests. It may use the JAX-RS framework, but using JAX-RS and all the trappings of REST does not make it REST, simply because it fails the stateless criteria.</li>
  <li>My app is badly designed - I should disregard trying to avoid the temporal and financial cost restacking up a statistical model even if it took 5 - 15 minutes for a workflow. Just make sure there is no dependence on previous requests. Repeat costly steps when necessary.</li>
  <li>The stateless criteria is outdated. My understanding of REST is outdated/defective in that REST community have been constantly ignoring this criteria.</li>
  </ul>
  
  <p>Is my app considered RESTful?</p>
  
  <p><strong>New Question:  ISO 9000</strong></p>
  
  <p>Finally, in case my app is not completely considered RESTFul, would all references to "REST" need to be omitted to pass ISO 9000 certification?</p>
  
  <p>new edit:</p>
  
  <p><strong>REST-in-piece</strong></p>
  
  <p>OK, my colleague and I have discussed this and decided to call such an architecture/pattern REST-in-piece = REST in piecemeal stages.</p>