One of the most common revision topics I encounter concerns representational state transfer (REST), a style of software architecture for distributed systems. In our creative multimedia degree, we use REST as the predominant web API design model.
I first read about REST in a W3C proposal back in 2001. It has become a web standard now.
Without realising it, a lot of us use REST-style architectures as web apps. The phones are the clients and the servers do the heavy lifting in a remote space. By tapping a screen, an app (a client, to use the terminology) initiates a requests. The server processes requests and returns appropriate responses. Requests and responses are built around the transfer of representations of resources. Handsets can do a lot of clever things when they get the data sets from servers.
By definition, "a representation of a resource is typically a document that captures the current or intended state of a resource."
I've told several students to remember these three things.
1. Clients begin the process by sending requests when they are ready to transition to a new state.
2. While one or more requests are outstanding, the client is considered to be in transition.
3. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.