(Fielding, 2000): "Software Architecture"

In this initial series, I’ll be working through Roy Fielding’s defining paper, Architectural Styles and the Design of Network-based Software Architectures, which is where he coined the term REST.

Theory

The title suggests that Fielding’s paper is primarily about software architecture, and he begins with a novel definition of it. A software architecture:

1. is “an abstraction of the run-time elements” (5)
2. is defined by its configuration and constraint of those element (7)
3. generally achieves a desirable set of properties (7)

Keep in mind that a system can exhibit various architectures in different phases of operation, and subsystems can each have their own architectures. Notice that a system’s architecture is composed of its run time elements. This means an element is a black box and identified by its externally observable behavior. Architectural elements can be classified as:

1. Components process and transform data. These are the boxes the usual “whiteboard diagram”.
2. Connectors mediate communicate and cooperation between components. These are the lines in diagrams.
3. Data is transferred between components via connectors. This is conspicuously missing from most diagrams.

Constraining these elements in certain ways will result in a system with predictable properties. A defined collection of constraints is called an architectural style, and REST is one such style. Joe Gregorio explains the difference between software architecture and architectural style clearly by the analogy of an Shaker house versus the Shaker style of architecture.

This means that REST is not HTTP. A REST style system needs to follow the constraints of REST, and as a result it will achieve a certain set of properties. We’ll go over both the constraints and benefits in following entries.

Practice

Fielding adopts a methodology for describing an architecture formalized by D.E. Perry and A.L. Wolf, which includes three views: process, connection, and data. For the purpose of illustration, I’ll be developing a simple application, and describing its architecture using these three views. I’ll provide and update its description as the it is built out.

Narrative

Here’s where I get to fill in the details of my particular interest in this subject. My organization, too, is being tempted by the allure of the next silver bullet. Unfortunately, despite the multitude self proclaimed RESTful APIs and the ubiquitous debate on virtues of REST, I find that many developers convey a disappointing understanding of the foundational concepts discussed by Fielding. My motivation in this investigation, therefore, is to to be able to apply use the principles of REST when appropriate. Let’s not be the next anecdote of how “design-by-buzzword is a common occurrence.”