Fielding's REST

Focus on the properties, not the constraints

This post is an excerpt from Mike Amundsen's book "RESTful Web API Patterns and Practices Cookbook" from O'Reilly Media.

As early as 1998, Roy T. Fielding made a presentation at Microsoft explaining his concept of Representational State Transfer (or REST as it is now known). In that talk, and his PhD dissertation that followed two years later (“Architectural Styles and the Design of Network-based Software Architectures”), Fielding put forth the idea that there was a unique set of software architectures for network-based implementations, and that one of the six styles he outlined—REST—was particularly suited for the Web.

• Often Cited…

  Years ago I learned the phrase, “Often cited, never read.” That snarky comment seems to apply quite well to Fielding’s dissertation from 2000. I encourage everyone working to create or maintain web-based software to take the time to read his dissertation—and not just the infamous Chapter 5, “Representational State Transfer”. His categorization of general styles over 20 years ago correctly describes styles that would later be known as gRPC, GraphQL, event-driven, containers, and others. 

Fielding’s method of identifying desirable system-level properties (like availability, performance, simplicity, modifiability, etc.), as well as a recommended set of constraints (client-server, statelessness, cacheability, etc.) selected to induce these properties, is still, more than two decades later, a valuable way to think about and design software that needs to be stable and functional over time.

A good way to sum up Fielding’s REST style comes from the dissertation itself:

"REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems."

The following is a list of Fielding’s architectural properties along with a brief summary of their use and meaning: 

• Performance
  The performance of a network-based solution is bound by physical network limitations (throughput, bandwidth, overhead, etc.) and user-perceived performance, such as request latency and the ability to reduce completion time through parallel requests.

• Scalability

  The ability of the architecture to support large numbers of components, or interactions among components, within an active configuration.

• Simplicity

  The primary means of inducing simplicity in your solutions is by applying the principle of separation of concerns to the allocation of functionality within components, and the principle of generality of interfaces.

• Modifiability

  The ease with which a change can be made to an application architecture via evolvability, extensibility, customizability, configurability, and reusability.

• Visibility

  The ability of a component to monitor or mediate the interaction between two other components using things like caches, proxies, and other mediators.

• Portability

  The ability to run the same software in different environments, including the ability to safely move code (e.g., JavaScript) as well as data between runtime systems (e.g., Linux, Windows, macOS, etc.)

• Reliability

  The degree to which an implementation is susceptible to system-level failures due to the failure of a single component (machine or service) within the network. 

The key reason I've relied on many of Fielding’s architectural principles is that they lead to implementations that scale and can be safely modified over long distances of space and time.