My notes on the Fielding Dissertation (REST)

These are my notes on Roy T. Fielding's famous Ph.D. dissertation "Architectural Styles and the Design of Network-based Software Architecture"

What follows are excerpts from the dissertation, with my notes usually in parentheses.

Roy Thomas Fielding is: chief Scientist in some tech company; Chairman, Apache Software Foundation; Visiting Scholar, W3C @ MIT CS Lab; etc; Publications, Honors, Awards, Fellowships etc. Involved in the authoring of the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI).

Abstract:

"The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system."

(He makes it sound as if it was designed this way on purpose.)

"In order to identify [...] aspects of the Web that needed improvement and avoid undesirable modifications, a model for the modern Web architecture was needed to guide its design, definition, and deployment."

(So, he admits the need to build a model after the fact.)

"An architectural style is a named, coordinated set of architectural constraints."



This dissertation defines a framework for understanding software architecture via architectural styles and demonstrates how styles can be used to guide the architectural design of network-based application software.

A survey of architectural styles for network-based applications is used to classify styles according to the architectural properties they induce on an architecture for distributed hypermedia.

I then introduce the Representational State Transfer (REST) architectural style and describe how REST has been used to guide the design and development of the architecture for the modern Web.

REST 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.

I describe the software engineering principles guiding REST and the interaction constraints chosen to
retain those principles, contrasting them to the constraints of other architectural styles.

Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol and Uniform Resource Identifier standards, and from their subsequent deployment in Web client and server software.

-------------------------------------------------------------

Introduction

The guideline that “form follows function” comes from hundreds of years of experience with failed building projects, but is often ignored by software practitioners.

"The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence."

(Aa-aa-aa-aa-meeeen, brutha!)

"This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction."

"My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. When given a name, a coordinated set of architectural constraints becomes an architectural style."

"Over the past six years, the REST architectural style has been used to guide the design and development of the architecture for the modern Web, as presented in Chapter 6."

(so, I am not sure I understand: did the author come up with REST, or is he just documenting it?)

Chapter 1

"This raises an important distinction between software architecture and what is typically referred to as software structure: the former is an abstraction of the run-time behavior of a software system, whereas the latter is a property of the static software source code"

Chapter 2

"The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing [6], or the equivalent of message passing if a more efficient mechanism can be selected at run-time based on the location of components [128]."

"Tanenbaum and van Renesse [127] make a distinction between distributed systems and network-based systems: a distributed system is one that looks to its users like an ordinary centralized system, but runs on multiple, independent CPUs. In contrast, network-based systems are those capable of operation across a network, but not necessarily in a fashion that is transparent to the user. In some cases it is desirable for the user to be aware of the difference between an action that requires a network request and one that is satisfiable on their local system, particularly when network usage implies an extra transaction cost [133]. This dissertation covers network-based systems by not limiting the candidate styles to those that preserve transparency for the user."

"An interesting observation about network-based applications is that the best application performance is obtained by not using the network. This essentially means that the most efficient architectural styles for a network-based application are those that can effectively minimize use of the network when it is possible to do so, through reuse of prior interactions (caching), reduction of the frequency of network interactions in relation to user actions (replicated data and disconnected operation), [...]"

"Scalability refers to the ability of the architecture to support large numbers of components, or interactions among components, within an active configuration." I do not think that's a good definition of scalability.

"Scalability can be improved by simplifying components, by distributing services across many components (decentralizing the interactions), and by controlling interactions and configurations as a result of monitoring."

(I think scalability is something better thought of as achieved or not achieved, rather than something sort of achieved and then improved upon.)

"Styles influence these factors by determining the location of application state, the extent of distribution, and the coupling between components."

(Interestingly enough, even though the author appears to have gotten the previous two
two sentences wrong, this conclusion appears to be correct.)

"Generality of connectors leads to middleware."

(I do not object to that, but I have no idea what the author is on to with it.)

"Modifiability is about the ease with which a change can be made to an application architecture. Modifiability can be further broken down into evolvability, extensibility, customizability, configurability, and reusability, as described below. A particular concern of network-based systems is dynamic modifiability [98], where the modification is made to a deployed application without stopping and restarting the entire system."

"the system must be prepared for gradual and fragmented change, where old and new implementations coexist, without preventing the new implementations from making use of their extended capabilities"

(I think this may be a fallacy, or at least only possible in trivial scenarios. I think that what is far more likely to happen is that the introduction of a new feature will be incompatible with keeping an old feature around in any way shape or form. Essentially, the only way for the old functionality to remain available will be by re-implementing the associated module so that it emulates the old functionality using the new functionality.  (Providing an "illusion" of the old functionality.) And then, should this completely rewritten reincarnation of the old implementation be allowed to keep the old version number?  In theory, if your testing is not just extremely robust but actually perfect, then yes.  In practice, no.)

"Evolvability represents the degree to which a component implementation can be changed without negatively impacting other components."

"Extensibility is defined as the ability to add functionality to a system. Dynamic extensibility implies that functionality can be added to a deployed system without impacting the rest of the system."

"Customizability refers to the ability to temporarily specialize the behavior of an architectural element, such that it can then perform an unusual service. A component is customizable if it can be extended by one client of that component’s services without adversely impacting other clients of that component. [...] Customizability is a property induced by the remote evaluation and code-on-demand styles"

"Configurability is related to both extensibility and reusability in that it refers to post-deployment modification of components, or configurations of components, such that they are capable of using a new service or data element type."

"Reusability is a property of an application architecture if its components, connectors, or data elements can be reused, without modification, in other applications. The primary mechanisms for inducing reusability within architectural styles is reduction of coupling (knowledge of identity) between components and constraining the generality of component interfaces."

(*Constraining* the generality of component interfaces?  Is that an error?  I thought that
the more general the interface, the more reusable the component.)

"Visibility [...] refers to the ability of a component to monitor or mediate the interaction between two other components."

"Software is portable if it can run in different environments."

"Reliability, within the perspective of application architectures, can be viewed as the degree to which an architecture is susceptible to failure at the system level in the presence of partial failures within components, connectors, or data. Styles can improve reliability by avoiding single points of failure, enabling redundancy, allowing monitoring, or reducing the scope of failure to a recoverable action."

Chapter 3

"The purpose of building software is not to create a specific topology of interactions or use a particular component type — it is to create a system that meets or exceeds the application needs. The architectural styles chosen for a system’s design must conform to those needs, not the other way around."

Chapter 4

"Working groups within the Internet Engineering Taskforce were formed to work on the Web’s three primary standards: URI, HTTP, and HTML. The charter of these groups was to define the subset of existing architectural communication that was commonly and consistently implemented in the early Web architecture, identify problems within that architecture, and then specify a set of standards to solve those problems." 

(yup, that pretty much sums it up: it began as chaos, and any attempts to put the chaos into order were post-hoc.)

"The next chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, as it has been developed to represent the model for how the modern Web should work. 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."

Chapter 5

"The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction."

"REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."

------------------------------------------------

continue on last paragraph of page 83