REST and Shared State Between Client and Server

Every now and then the question comes up where to draw the line on stateless communications as mandated in RESTful services. I remember one conversation at another job where a group said they couldn’t do such-and-such because it required shared state between the client and server. And that was that.

At the time, I knew that wasn’t right, but I’ve been wrestling with exactly why. Then last night it clicked. We share state between client and server all the time. Shopping carts, authentication and authorization status, what page a user is on, a step that a user just took and now we’re verifying, etc. There are tons of examples of where the client and server have to share state.

But it is bad when *A* client shares state with *A* server. If server #432 in your server farm blanks out, and you lose the state for a client, then, yes, you have server affinity. Or stickyness. And that is a bad thing.

But if your client comes to your server bank, and you share the client state either through some clustering, synchronization, or pushing the state into a distributed datastore or cache, then you’re OK. The acid test is, can I walk over to my server farm and pull the plug on a machine, or even a rack, and not lose track of what the clients are doing? If so, you’re OK.

That allows both reliability and scalability, because if a server goes away, there are lots others to take up the load. And since any one server isn’t remembering anything particular, then you can just add more servers and they’ll just join the mix.

So the pushback from that group was off-target. The problem isn’t with shared state in general — that’s the basis of REST. Rather, the prohibition is against *A* particular client sharing state with *A* particular server.

I just wanted to clear the air on that. Thank you for your time.



Filed under computer architecture, computer scaling, open standards, opinionizing, REST

5 responses to “REST and Shared State Between Client and Server

  1. Pingback: Distributed Weekly 161 — Scott Banwart's Blog

  2. I disagree with this, the point of the stateless constraint is to aid scalability and it is meant to cover any shared state between the server side and the client, regardless of how that is dealt with on the server side. If you are maintaining that shared state centrally and external to your web servers (say, in redis) that will help, but you will eventually run into issues there too. The constraint is meant to ensure that a message can be fully processed by the server on its own merit – if this is not the case then the request is not self-descriptive and cannot be reliably processed by intermediaries (e.g. a proxy cache), at which point the interaction may as well be RPC.

    Despite this, in many cases it is necessary to violate this constraint because it is eaiser to implement in practice; e.g. maintaining application state for your app within a browser is still relatively difficult if not impossible. But that doesn’t change that it’s a violation of the constraint and it will most likely cost you some degree of scalability. It’s a trade-off.

    • roby2358

      Good comment thank you!

      Let’s take a couple of concrete examples: can I manage a shopping cart through a RESTful interface if I put the shopping cart contents in a database?

      Or a longer-lived artifact like a hotel booking, which has several back-and-forths between client and server, maybe over a period of days. Can I manage a hotel booking through a RESTful interface without requiring my clients to hold all their own booking information? What if they cheat and tell us they’ve booked the penthouse suite?

      Do hypermedia links break REST? If I include a href in my representation, then the message isn’t completely self-descriptive either — there’s some other state elsewhere that’s part of the message.

      Moving to REST and stateless communications can’t require us to throw away server-side caches and datastores. REST is Representational State Transfer, after all. There’s a lot of shared state flowing in both directions in REST.

      Actually I think these sort of discussions get bogged down with what is protocol-level state, and what is resource state.

    • roby2358

      Actually, your comment was helpful — I think there’s a tendency to mix in data scalability with service scalability in these discussions. For example, problems that arise from managing data in Redis are a separate problem from the scalability of the service. In a way, if your service is stretching the limits of what Redis can support, then you’ve done your job: you service is more scalable than the datastore.

      As an overall architecture, it’s nice when you’re able to push client state back onto the client and make them responsible for it. It saves a lot of headaches in data management. But most of the time, services are in place to manage server-side data (i.e. state) as well as server-side processing. So REST wouldn’t even get off the ground if it prohibited shared state between client and server, because at the end of the day, that’s the whole point of REST. We just want to transfer that state in such a way that we’re not tied to any particular box in the middle.

  3. Pingback: This Week in #REST – Volume 44 (Apr 4 2012 – Aug 24 2012) « This week in REST

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s