Trying to Explain App State for REST

I will try a different approach to explain the concept of application state, which is usually confusing and a recurring question from REST newbies.

I want to play blackjack. I have some friends and we all go to the online blackjack service.

Each one of us enters the application, which allows us to play BJ. The main screen requests our IDs. At the next minute, we all but one are ready to play (the one still not ready is because he forgot the ID number).

Let's see what happens there. We are, say, ten clients, each one is using the application, nine of which are ready to play while one is waiting for ID input. As you can see, there is one application, but each client has a different application state now. And each client knows its state clearly.

So, we left our friend finding his number and we started to request cards. We knew there was a dealer at the other end of the line, but we were not able to know if we were all playing with the same dealer!

Still, there was just one mass of cards. Yes, each card requested changed the mass. Still more, each request may be served by a different dealer!

Careful here. You may get confused. Requesting a card using GET is like asking the dealer to show you the face of the top card. You get a representation, but the card stays in the deck. In real game, you want the card sent to you. In REST, you will post something (a "draw a card" request message) to the dealer, with the actual deck URL. The dealer will modify the deck, say removing the top card, and will redirect you to that card. Here, the mass of cards is a resource, the dealers are the servers.

Now, can you clearly see the difference of the states? Each request will change the resource state, but that is not the app state. Each client has its own state of the game (each player knows its hand), and that is the app state.

The actual server state may be dealer working or dealer in a break. So server state is actually another very different thing.

So, what is the REST constrain here? Well, if you program the dealer to know the hand of each client, you are violating REST, since then the server is actually controlling the state of the app for each user.

The idea is the client controls its app state, not the server. So, even when the client wins the hand, it will have to show it to the dealer, saying I won. And the dealer will give me the lollipop gift. And after that the dealer will wait again for another request.

Each request will contain all the information needed to be totally completed in one interaction. The sum of all interactions is your final goal, the application.

Also note the resource can be changed in the process, but that is not an app change.

Why is all that setup good? Well, you can have thousands of clients that it will not impact servers, since they do not keep track of the hands. You can add or remove dealers with no impact on the clients nor in the application states. You keep hidden the resource implementation. And you got then a nicely distributed game, scalable and simple.

Hope this helps!