Can REST in practice really be stateless? [closed]

Question

Consider the situation.

I am writing a statistical analysis app. The app has multiple tiers.

1. Frontend UI written for multiple device types, desktop, browser, mobile.
2. Mid-tier servlet that offers a so-called REST service to these frontend.
3. Backend that performs the extreme computation of the statistical processing.
4. Which communicates with a further backend database

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.

1. The statistical analyses consists of procedures or a series of work-flow steps.

2. Some steps may require so much processing power, you would not want to repeat them.

3. 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.

4. 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.

5. 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.

6. 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.

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.

Therefore, how true can the following statement be?

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.

Obviously, the application I described, requires that request be dependent on previous request. There are three possibilities that I can see concerning this app.

• 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.
• 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.
• The stateless criteria is outdated. My understanding of REST is outdated/defective in that REST community have been constantly ignoring this criteria.

Is my app considered RESTful?

New Question: ISO 9000

Finally, in case my app is not completely considered RESTFul, would all references to "REST" need to be omitted to pass ISO 9000 certification?

new edit:

REST-in-piece

OK, my colleague and I have discussed this and decided to call such an architecture/pattern REST-in-piece = REST in piecemeal stages.

Answer 1

ISTM, you're reading too much into to statelessness. A REST API supports traditional CRUD operations. The API for CouchDB is good example of how DB state is updated by a series of stateless transactions.

Your task is to identify what the resources are and the "state transfers" between them. Each step in your workflow is a different state transfer, marked by a different URI. Each update/change to a resource has an accompanying POST/PATCH or an idempotent PUT or DELETE operation.

If you want to gain a better of understanding of what is means to be RESTful and the reasons behind each design choice, I recommend spending a hour reading Chapter 5 of Roy Fielding's Dissertation.

When making design choices, just think about what the principles of RESTful design are trying to accomplish. Setup your design so that queries are safe (don't change state) and that they are done in a ways that can be bookmarkable, cacheable, distributable, etc. Let each step in the workflow jump to a new state with a distinct URI so that a user can back-up, branch out different ways, etc. The whole idea is to create a scalable, flexible design.