5.1 REST History and Analysis
Representational State Transfer (REST) [30] is a software architectural style that defines much of how information is currently transferred between previous unconnected, distinct web applications. REST APIs now compose approximately 71% of the global API market share [31], foot-holding as the foundation upon which many of the world’s most popular web services are serviced to consumers by developers.Any web application that deploys a REST architecture for API interaction, and in doing so become known as RESTful, must comply with five guiding constraints. These constraints restrict the ways that a server can process and respond to client query requests, but, in doing so, provide websites a number of desirable properties with regards to efficiency, scalability, and simplicity. The constraints are as follows:
Client-Server Architecture: The basic principle of client-server architecture is that there exists a clear separation between the data queried and the user-interface that the data provider typically utilizes to represent that data. To provide a concrete example, a Facebook API should not explicitly mirror Facebook’s own front-end interface. Thus, third-party developers who query a Facebook API should not be forced to interact with, for example, a Facebook ‘profile page’ endpoint but rather information about a ‘user,’ which the third-party developer can then utilize in their web application’s distinct user-interface.
Statelessness: No data that has been queried should be stored on the server in-between requests, such that servicing any additional query possesses a marginal cost of zero to the data provider. As such, every request made by a client developer must contain all the information necessary for the server to service that request.
Cacheability: Clients are able to cache responses. Caching means ‘store for later,’ which renders that the client can avoid asking a server for information if the client has already asked for it earlier. For example, if I request someone’s Facebook profile through the Facebook API, I can cache that information so that I don’t need to request it the next time I need it.
Layered Architecture: A client should not ordinarily be able to tell whether the client is connected directly to the provider’s end-server [32] or an intermediary server that exists between the end-server and the client. For example, if server-side web application utilizes a load balancer, a technology that allows developers to distribute requests across multiple servers such that no single server becomes inundated, the client requesting data from that web application should still continue fully performant communication with the layer of the server architecture providing the response, not requiring any additional code by the client or server architecture.
Uniform Interface: A uniform interface is, per third-party developer experiences, the most significant element of REST, distinguishing it from competing architectural styles. A uniform interface decouples a web application’s interface from its implementation, meaning that regardless what a web application does, developers can interact with its API in the same way. Thus, developers can interact with all of their provided REST APIs in exactly the same way, even if the information they are retrieving is entirely distinct. REST achieves this highly desirable malleability due to four constraints:
Identification of Resources: The REST style differs from preceding APIs because it is centered around resources as opposed to methods or procedures. These resources can effectively take any form (be it a static picture or a feed of real-time stock prices), but they usually represent entities from the business domain (customers, orders, prices, products, etc). Regardless of the data that the resource provides, the resource must be uniquely identifiable via a Uniform Resource Identifier (URI); notably, the resource’s identifier must be stable even if the resource itself is changed. For example, if Spotify were to update the album art for a given song, a develop would still to find it in the same query via their API; nothing would change for the developer reliant on the API.
Manipulation of Resources through Representation: A client not have direct access to a server-side database through the server’s API. If a client wishes to manipulate information through the server’s API, such as to change a user's profile picture, the client must grab a copy of that resource, manipulate it, send the updated representation to the server, and ask the server to update its underlying resource. The server can then decide if this is an appropriate change to make, thereby protecting the companies underlying data-store from malicious edits.
Self-Descriptive Messages: The Self-Descriptive Message constraint requires a message (be it a request or a response) to include enough information for the receiver to understand it in isolation. We’ll cover what this means in greater detail when describing how REST APIs work in practice below.
Hypermedia as the Engine of Application State: Any RESTful application should be entirely navigable through links. Navigable links has allowed end-user clients to navigate to any part of a website from a single ‘base’ URI, such as facebook.com, and, for developers requesting APIs, it means the developer doesn’t need to look at specified API documentation to purvey how to obtain a desired resource.
Code on Demand: A server can extend the functionality of a client at runtime by sending code to the client that the client should execute (like JavaApplets or JavaScript). This property is similar to the cacheability of REST, highlighting the architecture’s high performance.
Last updated