The S in REST stands for State. Unfortunately, state is an overloaded word.
In this post I’ll discuss the two different kinds of state that apply to REST APIs.
Applications
The first type of state is application state, as in Hypermedia As The Engine Of Application State (HATEOAS), the distinguishing feature of the REST architectural style.
We must first understand what exactly an application in a RESTful architecture is and isn’t. A REST API is not an interface to an application, but an interface for an application.
A RESTful service is just a bunch of interrelated and interconnected resources. In and of themselves they don’t make up an application. It’s a particular usage pattern of those resources that turn them into an application.
The term application pertains more to the client than to the server. It’s possible to build different applications on top of the same resources. It’s also possible to build an application out of resources hosted on different servers or even by different organizations (mashups).
Application State vs. Resource State
The stateless constraint of REST doesn’t say that a server can’t maintain any state, it only says that a server shouldn’t maintain application (or session) state.
A server is allowed to maintain other state. In fact, most servers would be completely useless if they didn’t. Think of the Amazon web store without any books! We call this resource state to distinguish it from application state.
So where do we draw the line between resource state and application state?
Resource state is information we want to be available between multiple sessions of the same user, and between sessions of different users. Resource state can initially be supplied by either servers (e.g. books) or clients (e.g. book reviews).
Application state is the information that pertains to one particular session of the application. The contents of my shopping cart could be application state, for instance.
Note that this is not how Amazon implemented it; they keep this state on the server. That doesn’t mean that the people at Amazon don’t understand REST. The web browser that I use to shop isn’t sophisticated enough to maintain the application state. Also, they want me to be able to close my browser and return to my shopping cart tomorrow.
This example shows that what is application and what resource state is a design decision.
Application state pertains to the goal the user is trying to achieve while driving the client. It is this state that we’re referring to when we talk about state diagrams for REST APIs, not the resource state.
State Transfer
Application state is all the information maintained on the client side while the user is trying to accomplish a goal. This information is built up piece by piece based on the resource state that is transferred between client and server.
The resource state is transferred as a representation, a particular serialization of the resource state suitable for inclusion in an HTTP message body.
Serialization is governed by the rules laid out in a media type. There are many different media types, some more mature than others.
Since clients and servers transfer representations of resource state, we speak of Representational State Transfer (REST).
| Reference: | The State of REST from our JCG partner Remon Sinnema at the Secure Software Development blog. |
