REST stands for “Representational State Transfer”, which is kind of funny if you think about it, because it is an architectural style based on stateless communications. It says, use stateless communications to transfer state.
Which, if you think about it hard enough, starts to sound a little like a practical joke someone played on us.
So what’s the state that we’re transferring, and at what point do we cross the line into non-stateless communication?
It seems to me that it comes down to the idea of Resource after all. And in REST, you have to remember that “Resource” is just a huge umbrella term that pretty much covers all the information in any system sitting behind a RESTful interface. When you consider what a Resource is, you have to thing VERY VERY broadly.
A resource is just a view into data in the system. In my mind, when you say resource, its just a fancy, and slightly unfortunate, way to say information. REST could just as easily been formulated as an architectural style for transferring “addressable information” as “addressable resources”.
OK so enough skirting the issue. What is state anyway?
Well, it’s the current value of anything that sits *behind* the API of our system. It could be as narrow as the values in a row in a database, and it could be as broad as an assembled structure of data pulled from a federated system of datastores. The state may represent values of information in caches, or it may be completely ephemeral, and represent the value of a calculation done on the fly.
So when it comes time to issues like authentication and authorization, really the state you’re representing isn’t just “a view of the current values of a customer record”, but “a view of the current values of a customer record as permitted by the current state of your authentication and the state of your authorization level.”
If we want to represent the data in our RESTful system as a state machine, we have to make sure that any “non-functional” concerns like login are included in that state machine. Normally we’d just model the “functional” concerns — i.e. those concerns that are a part of the problem domain. The non-functional concerns are ones that we don’t want to put in our spec, because we want to focus on the functionality of the system. But from the point of view of REST, the non-functional concerns are also a part of the Resource.
The point of statelessness in REST is to defeat the idea of server affinity. We don’t want to have a single server being a single point of failure. We want to be able to freely hop from server to server in the bank, and not worry about it. We also don’t want to have to worry about clustering or sharing data at the protocol level. We just want a generic server to pick up our request, look at it, and go to town.
But the underlying resource is, by definition, stateful. The architecture is “Representational State Transfer” after all. So you have to watch out for the same sorts of problems — single points of failure, distributed datastores, etc. — except that at the Resource layer, you *must* maintain state. That’s the whole point.
So when you have a conversation about statelessness in this architecture that is oriented around sending or changing state, bear in mind that the stateless part is really about stateless communications, to allow flexibility in the infrastructure. Beyond that, when you get into the area of Resources, it’s pretty much the wild, wild west.
LOL let me know if there’s a better way to say that. There must be.