How to distinguish application state and resource state

Question

I know that to make a stateless application, we need to transfer the user state back and forth instead of server holds the user state.

However, there must be some states stored in the server, I read this article that the state stored in server is called resource state.So if I am right, client state which we often call should be the same as application state.

So, how do I distinguish these two, since it will determine that whether they should stored in server or transferred.

Take a shopping cart as an example.

1. If there is 5 steps before a user to complete his purchase, the user's phase where he is(#3,#4) in seems to be an application state, but does this mean if they close the browser and click on pay again, he will have to start from the step1?

2. What about the items in his chart? If we treat it as application state, we need to put all of the items in the request. But if we do this, when user close the browser and login again, he will not able to find his items again, since the browser can not remember all the items. So it seems we should treat it as a resource state. But if so, when a user click on pay , they will have a different page: go to pay or say "your cart is empty" based on whether his shopping cart is empty or not. So , the same requests with exactly the same param input, comes out the different result, can we still say it is stateless?

Maybe I understand something wrong, can any body please answer how to distinguish different kinds of state and how to treat them differently?

Vallonia

Answer 1

Resource state is a state that needs to be persistent and survivable even after client disconnect/restart/session end/whatever. Application state should live on the client and should be supplied with each client request(if we are talking about REST architecture and planning to scale our application well).

How to distinguish application state and resource state?

It depends on the task your are working on. E.g. if you are trying to figure out where to save index of the picture that is currently viewed in your gallery, probably, you could do it in your Application state, because you, likely, don't need this state to survive for the next session of this client. Of course, you can save it in your Resource state(database), but it would be overhead(a lot of effort for a very small gain).

But if your are working on multistep purchasing process, probably, it's better to save state of this process in your Resource state(database), because you want this state to be saved permanently. Otherwise, your clients need to refill a lot of information after disconnect/restart/whatever. Of course you could do it in cookies for example(and it would be Application state), and this state can live after browser restart. But it has the two downsides: 1)This state unavailable on other user's devices, 2)If you are creating genuine REST service, cookies would complicate client's life, because not all clients operate cookies well(except browsers).

Marishamariska

Answer 2

Let me just quote one paragraph of the book RESTful Web Services :

The Flickr web service lets you upload pictures to your account, and those pictures are stored on the server. It would be crazy to make the client send every one of its pictures along with every request to flickr.com, just to keep the server from having to store any state

The application state is related to the path that the client can follow to make some actions. For example, when consulting an article, a link "add to cart" appears. When consulting his cart, a link "pay your order" is provided if you have one article in your cart otherwise this link does not appears. Feel free to the user to make its own application state based on the link that he follows. Basically, application state is a matter of context.

One other quote from the same book mentionned earlier before I go back to you example:

Resource state stays on the server and is only sent to the client in the form of representations. Application state stays on the client until it can be used to create, modify, or delete a resource. Then it’s sent to the server as part of a POST, PUT, or DELETE request, and becomes resource state.

So let's say that you have some authentification mechanism (based on token). And to one user account is associated one cart. When you are adding items in your cart, you are modifying your cart resource. As resource state are server-side, it's on server.
Suppose that you disconnect, and reconnect like described in your first point. The cart is still here.
As long as the client send the different authentification credential at each request, your application remains stateless.

A good discussion on SO about how to manage it: Do sessions really violate RESTfulness?

Now, what about the fact that: consulting your cart can leads you to 2 different action depending on whether it has items or not.
Pretty simple. What is served by the server to the client depends on the resource state maintains by the server.
A very simple example on this good website. You can see that depending on the amount of money on the account, the server provides a link to the client to make a withdraw or not.
Feel free to the client to make its own application (again) and to follow the link or not.

I recommand you to take a look at HATEOAS and the Richardson Maturity Model that explains it. By the way, the quotes from the 2 paragraphs are from the same author that this model.

Railhead