REST — What is State, anyway?

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.



Filed under open standards, REST

6 responses to “REST — What is State, anyway?

  1. Pingback: This Week in #REST – Volume 33 (Jan 29 2011 – Feb 8 2011) « This week in REST

  2. The stateless constraint just means you should try to avoid *shared* state between client and server because it erodes visibility and makes layering harder.

    You know how cookies work.. Just don’t do that, basically.

    • roby2358

      Thank you for your comment! That’s a really good point.

      Let me be annoying for a second (my wife complains about that all the time) and ask even if I agree with you and don’t like cookies, are they really bad in the REST context?

      REST is all about state transfer, and if you’re passing information back and forth in a cookie, you’re still just transferring resource state.

      A cookie isn’t bound to a box, so if one server emits a cookie, another in the bank might get the cookie on the way back and use it to look up rows in a database, or whatever.

      Now, maybe it’s cheating — passing state information in the header, rather than in the body or query string — but HTTP allows for that, even though the cookie spec is crap. And I actually agree with you strongly that it’s a bad idea.

      I think your statement about shared state is right on, though. My opinion (I could be wrong) is that Fielding was complaining about protocols that involve a lot of ACKs and handshakes and low-level things being shared between client and server at the protocol level.

      Most of us are so used to just using HTTP that we hardly even think about that. We just take stateless communications for granted. But if you open a socket to a server (not stateless!) and start using bi-directional communication, then you’ve really violated the basic premise.

      Does that sound about right?

    • László Lajos Jánszky

      Cookies are ok. Session cookies with session manager in the REST service are not ok… 🙂
      Btw. there are 2 states here: resource state and application state. If the amount of data increases with the numbers of active sessions, then that data belongs to client state, if not, then it belongs to resource state. Resource state is maintained by the REST service, application state is maintained by the REST client (normally). A http only cookie, which is set by the service, and which contains the username and the password is a very good question. 🙂 It is stored by the client, but it is maintained by the service, because only it can set http only cookies. So it is on the edge of statelessness… I think it is not a problem to use this kind of cookies, because they do not impact the scalability of the REST service.

      • roby2358

        I agree, I think the central question is: does it impact reliability or scalability? Can I turn a server off without forgetting any clients? Can I add a new server and have it start handling requests right away? If so, then I’m handling state correctly.

        Stateful servers aren’t a philosophical or spiritual problem. It’s just about managing servers.

  3. Pingback: Distributed Weekly 89 — Scott Banwart's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s