UNIVERSITY OF CALIFORNIA,
IRVINE
Architectural Styles and the Design of Network-based Software Architectures
DISSERTATION
submitted in partial satisfaction of the requirements for the degree of
DOCTOR OF PHILOSOPHY
in Information and Computer Science
by
Roy Thomas Fielding
Dissertation Committee:
Professor Richard N. Taylor, Chair
Professor Mark S. Ackerman
Professor David S. Rosenblum
2000

© Roy Thomas Fielding, 2000.
All rights reserved.

ii
The dissertation of Roy Thomas Fielding is approved
and is acceptable in quality and form
for publication on microfilm:
____________________________________
____________________________________
____________________________________
Committee Chair
University of California, Irvine
2000

iii
DEDICATION
To
my parents,
Pete and Kathleen Fielding,
who made all of this possible,
for their endless encouragement and patience.
And also to
Tim Berners-Lee,
for making the World Wide Web an open, collaborative project.
What is life?
It is the flash of a firefly in the night.
It is the breath of a buffalo in the wintertime.
It is the little shadow which runs across the grass
and loses itself in the sunset.
— Crowfoot's last words (1890), Blackfoot warrior and orator.
Almost everybody feels at peace with nature: listening to the ocean
waves against the shore, by a still lake, in a field of grass, on a
windblown heath. One day, when we have learned the timeless way
again, we shall feel the same about our towns, and we shall feel as
much at peace in them, as we do today walking by the ocean, or
stretched out in the long grass of a meadow.
— Christopher Alexander, The Timeless Way of Building (1979)

TABLE OF CONTENTS
Page
LIST OF FIGURES .......................................................................................vi
LIST OF TABLES........................................................................................vii
ACKNOWLEDGMENTS ...........................................................................viii
CURRICULUM VITAE.................................................................................x
ABSTRACT OF THE DISSERTATION ....................................................xvi
INTRODUCTION ..........................................................................................1
CHAPTER 1: Software Architecture ..............................................................5
1.1 Run-time Abstraction............................................................................................5
1.2 Elements................................................................................................................7
1.3 Configurations ....................................................................................................12
1.4 Properties ............................................................................................................12
1.5 Styles...................................................................................................................13
1.6 Patterns and Pattern Languages ..........................................................................16
1.7 Views ..................................................................................................................17
1.8 Related Work ......................................................................................................18
1.9 Summary.............................................................................................................23
CHAPTER 2: Network-based Application Architectures.............................24
2.1 Scope...................................................................................................................24
2.2 Evaluating the Design of Application Architectures ..........................................26
2.3 Architectural Properties of Key Interest .............................................................28
2.4 Summary.............................................................................................................37iv

CHAPTER 3: Network-based Architectural Styles ......................................38
3.1 Classification Methodology................................................................................38
3.2 Data-flow Styles .................................................................................................41
3.3 Replication Styles ...............................................................................................43
3.4 Hierarchical Styles ..............................................................................................45
3.5 Mobile Code Styles.............................................................................................50
3.6 Peer-to-Peer Styles..............................................................................................55
3.7 Limitations ..........................................................................................................59
3.8 Related Work ......................................................................................................60
3.9 Summary.............................................................................................................64
CHAPTER 4: Designing the Web Architecture: Problems and Insights ......66
4.1 WWW Application Domain Requirements ........................................................66
4.2 Problem...............................................................................................................71
4.3 Approach.............................................................................................................72
4.4 Summary.............................................................................................................75
CHAPTER 5: Representational State Transfer (REST)................................76
5.1 Deriving REST ...................................................................................................76
5.2 REST Architectural Elements.............................................................................86
5.3 REST Architectural Views .................................................................................97
5.4 Related Work ....................................................................................................103
5.5 Summary...........................................................................................................105
CHAPTER 6: Experience and Evaluation ..................................................107
6.1 Standardizing the Web......................................................................................107
6.2 REST Applied to URI.......................................................................................109
6.3 REST Applied to HTTP....................................................................................116
6.4 Technology Transfer.........................................................................................134
6.5 Architectural Lessons .......................................................................................138
6.6 Summary...........................................................................................................147
CONCLUSIONS.........................................................................................148
REFERENCES............................................................................................152v

vi
LIST OF FIGURES
Page
Figure 5-1. Null Style 77
Figure 5-2. Client-Server 78
Figure 5-3. Client-Stateless-Server 78
Figure 5-4. Client-Cache-Stateless-Server 80
Figure 5-5. Early WWW Architecture Diagram 81
Figure 5-6. Uniform-Client-Cache-Stateless-Server 82
Figure 5-7. Uniform-Layered-Client-Cache-Stateless-Server 83
Figure 5-8. REST 84
Figure 5-9. REST Derivation by Style Constraints 85
Figure 5-10. Process View of a REST-based Architecture 98

vii
LIST OF TABLES
Page
Table 3-1. Evaluation of Data-flow Styles for Network-based Hypermedia 41
Table 3-2. Evaluation of Replication Styles for Network-based Hypermedia 43
Table 3-3. Evaluation of Hierarchical Styles for Network-based Hypermedia 45
Table 3-4. Evaluation of Mobile Code Styles for Network-based Hypermedia 51
Table 3-5. Evaluation of Peer-to-Peer Styles for Network-based Hypermedia 55
Table 3-6. Evaluation Summary 65
Table 5-1. REST Data Elements 88
Table 5-2. REST Connectors 93
Table 5-3. REST Components 96

ACKNOWLEDGMENTS
It has been a great pleasure working with the faculty, staff, and students at the University
of California, Irvine, during my tenure as a doctoral student. This work would never have
been possible if it were not for the freedom I was given to pursue my own research
interests, thanks in large part to the kindness and considerable mentoring provided by
Dick Taylor, my long-time advisor and committee chair. Mark Ackerman also deserves a
great deal of thanks, for it was his class on distributed information services in 1993 that
introduced me to the Web developer community and led to all of the design work
described in this dissertation. Likewise, it was David Rosenblum’s work on Internet-scale
software architectures that convinced me to think of my own research in terms of
architecture, rather than simply hypermedia or application-layer protocol design.
The Web’s architectural style was developed iteratively over a six year period, but
primarily during the first six months of 1995. It has been influenced by countless
discussions with researchers at UCI, staff at the World Wide Web Consortium (W3C), and
engineers within the HTTP and URI working groups of the Internet Engineering
Taskforce (IETF). I would particularly like to thank Tim Berners-Lee, Henrik Frystyk
Nielsen, Dan Connolly, Dave Raggett, Rohit Khare, Jim Whitehead, Larry Masinter, and
Dan LaLiberte for many thoughtful conversations regarding the nature and goals of the
WWW architecture. I’d also like to thank Ken Anderson for his insight into the open
hypertext community and for trailblazing the path for hypermedia research at UCI. Thanks
also to my fellow architecture researchers at UCI, all of whom finished before me,
including Peyman Oreizy, Neno Medvidovic, Jason Robbins, and David Hilbert.
The Web architecture is based on the collaborative work of dozens of volunteer software
developers, many of whom rarely receive the credit they deserve for pioneering the Web
before it became a commercial phenomenon. In addition to the W3C folks above,
recognition should go to the server developers that enabled much of the Web’s rapid
growth in 1993-1994 (more so, I believe, than did the browsers). That includes
Rob McCool (NCSA httpd), Ari Luotonen (CERN httpd/proxy), and Tony Sanders
(Plexus). Thanks also to “Mr. Content”, Kevin Hughes, for being the first to implement
most of the interesting ways to show information on the Web beyond hypertext. The early
client developers also deserve thanks: Nicola Pellow (line-mode), Pei Wei (Viola),
Tony Johnson (Midas), Lou Montulli (Lynx), Bill Perry (W3), and Marc Andreessen and
Eric Bina (Mosaic for X). Finally, my personal thanks go to my libwww-perl
collaborators, Oscar Nierstrasz, Martijn Koster, and Gisle Aas. Cheers!viii

[4] Human Communication and the Design of the Modern Web Architecture. WebNet
World Conference on the WWW and the Internet (WebNet 99), Honolulu, HI,
October 1999.
[5] The Apache Software Foundation. Computer & Communications Industry
Association, Autumn Members Meeting, Dallas, TX, September 1999.
[6] Uniform Resource Identifiers. The Workshop on Internet-scale Technology
(TWIST 99), Irvine, CA, August 1999.
[7] Apache: Past, Present, and Future. Web Design World, Seattle, WA, July 1999.
[8] Progress Report on Apache. ZD Open Source Forum, Austin, TX, June 1999.
[9] Open Source, Apache-style: Lessons Learned from Collaborative Software
Development. Second Open Source and Community Licensing Summit, San Jose,
CA, March 1999.
[10] The Apache HTTP Server Project: Lessons Learned from Collaborative Software.
AT&T Labs — Research, Folsom Park, NJ, October 1998.
[11] Collaborative Software Development: Joining the Apache Project. ApacheCon ‘98,
San Francisco, CA, October 1998.
[12] Representational State Transfer: An Architectural Style for Distributed Hypermedia
Interaction. Microsoft Research, Redmond, WA, May 1998.
[13] The Apache Group: A Case Study of Internet Collaboration and Virtual
Communities. UC Irvine Social Sciences WWW Seminar, Irvine, CA, May 1997.
[14] WebSoft: Building a Global Software Engineering Environment. Workshop on
Software Engineering (on) the World Wide Web, 1997 International Conference on
Software Engineering (ICSE 97), Boston, MA, May 1997.
[15] Evolution of the Hypertext Transfer Protocol. ICS Research Symposium, Irvine,
CA, January 1997.
[16] World Wide Web Infrastructure and Evolution. IRUS SETT Symposium on
WIRED: World Wide Web and the Internet, Irvine, CA, May 1996.
[17] HTTP Caching. Fifth International World Wide Web Conference (WWW5), Paris,
France, May 1996.
[18] The Importance of World Wide Web Infrastructure. California Software Symposium
(CSS ‘96), Los Angeles, CA, April 1996.
[19] World Wide Web Software: An Insider’s View. IRUS Bay Area Roundtable (BART),
Palo Alto, CA, January 1996.
[20] libwww-Perl4 and libwww-Ada95. Fourth International World Wide Web
Conference, Boston, MA, December 1995.
[21] Hypertext Transfer Protocol — HTTP/1.x. Fourth International World Wide Web
Conference, Boston, MA, December 1995.xiii

[22] Hypertext Transfer Protocol — HTTP/1.x. HTTP Working Group, 34th Internet
Engineering Taskforce Meeting, Dallas, TX, December 1995.
[23] Hypertext Transfer Protocol — HTTP/1.0 and HTTP/1.1. HTTP Working Group,
32nd Internet Engineering Taskforce Meeting, Danvers, MA, April 1995.
[24] WWW Developer Starter Kits for Perl. WebWorld Conference, Orlando, FL,
January 1995, and Santa Clara, CA, April 1995.
[25] Relative Uniform Resource Locators. URI Working Group, 31st Internet
Engineering Taskforce Meeting, San Jose, CA, December 1994.
[26] Hypertext Transfer Protocol — HTTP/1.0. HTTP BOF, 31st Internet Engineering
Taskforce Meeting, San Jose, CA, December 1994.
[27] Behind the Curtains: How the Web was/is/will be created. UC Irvine Social Sciences
World Wide Web Seminar, Irvine, CA, October 1995.
[28] Maintaining Distributed Hypertext Infostructures: Welcome to MOMspider’s Web.
First International World Wide Web Conference, Geneva, Switzerland, May 1994.
Professional Activities
 Webmaster, 1997 International Conference on Software Engineering (ICSE’97),
Boston, May 1997.
 HTTP Session Chair, Fifth International World Wide Web Conference (WWW5),
Paris, France, May 1996.
 Birds-of-a-Feather Chair and Session Chair, Fourth International World Wide Web
Conference (WWW4), Boston, December 1995.
 Student Volunteer, 17th International Conference on Software Engineering (ICSE 17),
Seattle, June 1995.
 Student Volunteer, Second International World Wide Web Conference (WWW2),
Chicago, October 1994.
 Student Volunteer, 16th International Conference on Software Engineering (ICSE 16),
Sorrento, Italy, April 1994.
 Co-founder and member, The Apache Group, 1995-present.
 Founder and chief architect, libwww-perl collaborative project, 1994-95.
 ICS Representative, Associated Graduate Students Council, 1994-95.
Professional Associations
 The Apache Software Foundation
 Association for Computing Machinery (ACM)
 ACM Special Interest Groups on Software Engineering (SIGSOFT),
Data Communications (SIGCOMM), and Groupware (SIGGROUP)xiv

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. At least some of this behavior within the
software industry is due to a lack of understanding of why a given set of architectural
constraints is useful. In other words, the reasoning behind good software architectures is
not apparent to designers when those architectures are selected for reuse.
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.
The first three chapters of this dissertation define a framework for understanding
software architecture via architectural styles, revealing how styles can be used to guide the
architectural design of network-based application software. Common architectural styles2

CHAPTER 1
Software Architecture
In spite of the interest in software architecture as a field of research, there is little
agreement among researchers as to what exactly should be included in the definition of
architecture. In many cases, this has led to important aspects of architectural design being
overlooked by past research. This chapter defines a self-consistent terminology for
software architecture based on an examination of existing definitions within the literature
and my own insight with respect to network-based application architectures. Each
definition, highlighted within a box for ease of reference, is followed by a discussion of
how it is derived from, or compares to, related research.
1.1 Run-time Abstraction
At the heart of software architecture is the principle of abstraction: hiding some of the
details of a system through encapsulation in order to better identify and sustain its
properties [117]. A complex system will contain many levels of abstraction, each with its
own architecture. An architecture represents an abstraction of system behavior at that
level, such that architectural elements are delineated by the abstract interfaces they
provide to other elements at that level [9]. Within each element may be found another
architecture, defining the system of sub-elements that implement the behavior represented
A software architecture is an abstraction of the run-time elements of a
software system during some phase of its operation. A system may be
composed of many levels of abstraction and many phases of operation,
each with its own software architecture.5

by the parent element’s abstract interface. This recursion of architectures continues down
to the most basic system elements: those that cannot be decomposed into less abstract
elements.
In addition to levels of architecture, a software system will often have multiple
operational phases, such as start-up, initialization, normal processing, re-initialization, and
shutdown. Each operational phase has its own architecture. For example, a configuration
file will be treated as a data element during the start-up phase, but won’t be considered an
architectural element during normal processing, since at that point the information it
contained will have already been distributed throughout the system. It may, in fact, have
defined the normal processing architecture. An overall description of a system architecture
must be capable of describing not only the operational behavior of the system’s
architecture during each phase, but also the architecture of transitions between phases.
Perry and Wolf [105] define processing elements as “transformers of data,” while
Shaw et al. [118] describe components as “the locus of computation and state.” This is
further clarified in Shaw and Clements [122]: “A component is a unit of software that
performs some function at run-time. Examples include programs, objects, processes, and
filters.” 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. Although there are advantages to having the modular structure of the source code
match the decomposition of behavior within a running system, there are also advantages to
having independent software components be implemented using parts of the same code
(e.g., shared libraries). We separate the view of software architecture from that of the6

interactions among those components. In addition to specifying the structure and topology
of the system, the architecture shows the intended correspondence between the system
requirements and elements of the constructed system. Further elaboration of this definition
can be found in Shaw and Garlan [121].
What is surprising about the Shaw et al. [118] model is that, rather than defining the
software’s architecture as existing within the software, it is defining a description of the
software’s architecture as if that were the architecture. In the process, software
architecture as a whole is reduced to what is commonly found in most informal
architecture diagrams: boxes (components) and lines (connectors). Data elements, along
with many of the dynamic aspects of real software architectures, are ignored. Such a
model is incapable of adequately describing network-based software architectures, since
the nature, location, and movement of data elements within the system is often the single
most significant determinant of system behavior.
1.2.1 Components
Components are the most easily recognized aspect of software architecture. Perry and
Wolf’s [105] processing elements are defined as those components that supply the
transformation on the data elements. Garlan and Shaw [53] describe components simply
as the elements that perform computation. Our definition attempts to be more precise in
making the distinction between components and the software within connectors.
A component is an abstract unit of software instructions and internal state that
provides a transformation of data via its interface. Example transformations include
A component is an abstract unit of software instructions and internal
state that provides a transformation of data via its interface.9

loading into memory from secondary storage, performing some calculation, translating to
a different format, encapsulation with other data, etc. The behavior of each component is
part of the architecture insofar as that behavior can be observed or discerned from the
point of view of another component [9]. In other words, a component is defined by its
interface and the services it provides to other components, rather than by its
implementation behind the interface. Parnas [101] would define this as the set of
assumptions that other architectural elements can make about the component.
1.2.2 Connectors
Perry and Wolf [105] describe connecting elements vaguely as the glue that holds the
various pieces of the architecture together. A more precise definition is provided by Shaw
and Clements [122]: A connector is an abstract mechanism that mediates communication,
coordination, or cooperation among components. Examples include shared
representations, remote procedure calls, message-passing protocols, and data streams.
Perhaps the best way to think about connectors is to contrast them with components.
Connectors enable communication between components by transferring data elements
from one interface to another without changing the data. Internally, a connector may
consist of a subsystem of components that transform the data for transfer, perform the
transfer, and then reverse the transformation for delivery. However, the external
behavioral abstraction captured by the architecture ignores those details. In contrast, a
component may, but not always will, transform data from the external perspective.
A connector is an abstract mechanism that mediates communication,
coordination, or cooperation among components.10

1.2.3 Data
As noted above, the presence of data elements is the most significant distinction between
the model of software architecture defined by Perry and Wolf [105] and the model used by
much of the research labelled software architecture [1, 5, 9, 53, 56, 117-122, 128].
Boasson [24] criticizes current software architecture research for its emphasis on
component structures and architecture development tools, suggesting that more focus
should be placed on data-centric architectural modeling. Similar comments are made by
Jackson [67].
A datum is an element of information that is transferred from a component, or received
by a component, via a connector. Examples include byte-sequences, messages, marshalled
parameters, and serialized objects, but do not include information that is permanently
resident or hidden within a component. From the architectural perspective, a “file” is a
transformation that a file system component might make from a “file name” datum
received on its interface to a sequence of bytes recorded within an internally hidden
storage system. Components can also generate data, as in the case of a software
encapsulation of a clock or sensor.
The nature of the data elements within a network-based application architecture will
often determine whether or not a given architectural style is appropriate. This is
particularly evident in the comparison of mobile code design paradigms [50], where the
choice must be made between interacting with a component directly or transforming the
component into a data element, transferring it across a network, and then transforming it
A datum is an element of information that is transferred from a
component, or received by a component, via a connector.11

back to a component that can be interacted with locally. It is impossible to evaluate such
an architecture without considering data elements at the architectural level.
1.3 Configurations
Abowd et al. [1] define architectural description as supporting the description of systems
in terms of three basic syntactic classes: components, which are the locus of computation;
connectors, which define the interactions between components; and configurations, which
are collections of interacting components and connectors. Various style-specific concrete
notations may be used to represent these visually, facilitate the description of legal
computations and interactions, and constrain the set of desirable systems.
Strictly speaking, one might think of a configuration as being equivalent to a set of
specific constraints on component interaction. For example, Perry and Wolf [105] include
topology in their definition of architectural form relationships. However, separating the
active topology from more general constraints allows an architect to more easily
distinguish the active configuration from the potential domain of all legitimate
configurations. Additional rationale for distinguishing configurations within architectural
description languages is presented in Medvidovic and Taylor [86].
1.4 Properties
The set of architectural properties of a software architecture includes all properties that
derive from the selection and arrangement of components, connectors, and data within the
system. Examples include both the functional properties achieved by the system and non-
A configuration is the structure of architectural relationships among
components, connectors, and data during a period of system run-time.12

functional properties, such as relative ease of evolution, reusability of components,
efficiency, and dynamic extensibility, often referred to as quality attributes [9].
Properties are induced by the set of constraints within an architecture. Constraints are
often motivated by the application of a software engineering principle [58] to an aspect of
the architectural elements. For example, the uniform pipe-and-filter style obtains the
qualities of reusability of components and configurability of the application by applying
generality to its component interfaces — constraining the components to a single interface
type. Hence, the architectural constraint is “uniform component interface,” motivated by
the generality principle, in order to obtain two desirable qualities that will become the
architectural properties of reusable and configurable components when that style is
instantiated within an architecture.
The goal of architectural design is to create an architecture with a set of architectural
properties that form a superset of the system requirements. The relative importance of the
various architectural properties depends on the nature of the intended system. Section 2.3
examines the properties that are of particular interest to network-based application
architectures.
1.5 Styles
Since an architecture embodies both functional and non-functional properties, it can be
difficult to directly compare architectures for different types of systems, or for even the
An architectural style is a coordinated set of architectural constraints
that restricts the roles/features of architectural elements and the allowed
relationships among those elements within any architecture that
conforms to that style.13

same type of system set in different environments. Styles are a mechanism for
categorizing architectures and for defining their common characteristics [38]. Each style
provides an abstraction for the interactions of components, capturing the essence of a
pattern of interaction by ignoring the incidental details of the rest of the architecture [117].
Perry and Wolf [105] define architectural style as an abstraction of element types and
formal aspects from various specific architectures, perhaps concentrating on only certain
aspects of an architecture. An architectural style encapsulates important decisions about
the architectural elements and emphasizes important constraints on the elements and their
relationships. This definition allows for styles that focus only on the connectors of an
architecture, or on specific aspects of the component interfaces.
In contrast, Garlan and Shaw [53], Garlan et al. [56], and Shaw and Clements [122] all
define style in terms of a pattern of interactions among typed components. Specifically, an
architectural style determines the vocabulary of components and connectors that can be
used in instances of that style, together with a set of constraints on how they can be
combined [53]. This restricted view of architectural styles is a direct result of their
definition of software architecture — thinking of architecture as a formal description,
rather than as a running system, leads to abstractions based only in the shared patterns of
box and line diagrams. Abowd et al. [1] go further and define this explicitly as viewing the
collection of conventions that are used to interpret a class of architectural descriptions as
defining an architectural style.
New architectures can be defined as instances of specific styles [38]. Since
architectural styles may address different aspects of software architecture, a given14

described in [53], including information on the kinds of problems best suited to each
architecture. Buschmann et al. [28] provide a comprehensive examination of the
architectural patterns common to object-based development. Both references are purely
descriptive and make no attempt to compare or illustrate the differences among
architectural patterns.
Tepfenhart and Cusick [129] use a two dimensional map to differentiate among
domain taxonomies, domain models, architectural styles, frameworks, kits, design
patterns, and applications. In the topology, design patterns are predefined design
structures used as building blocks for a software architecture, whereas architectural styles
are sets of operational characteristics that identify an architectural family independent of
application domain. However, they fail to define architecture itself.
1.8.3 Reference Models and Domain-specific Software Architectures (DSSA)
Reference models are developed to provide conceptual frameworks for describing
architectures and showing how components are related to each other [117]. The Object
Management Architecture (OMA), developed by the OMG [96] as a reference model for
brokered distributed object architectures, specifies how objects are defined and created,
how client applications invoke objects, and how objects can be shared and reused. The
emphasis is on management of distributed objects, rather than efficient application
interaction.
Hayes-Roth et al. [62] define domain-specific software architecture (DSSA) as
comprising: a) a reference architecture, which describes a general computational
framework for a significant domain of applications, b) a component library, which20

unclear as to how CHAM could be used to describe any form of architecture whose
purpose goes beyond transforming a data stream.
Rapide [78] is a concurrent, event-based simulation language specifically designed for
defining and simulating system architectures. The simulator produces a partially-ordered
set of events that can be analyzed for conformance to the architectural constraints on
interconnection. Le Métayer [75] presents a formalism for the definition of architectures
in terms of graphs and graph grammars.
1.9 Summary
This chapter examined the background for this dissertation. Introducing and formalizing a
consistent set of terminology for software architecture concepts is necessary to avoid the
confusion between architecture and architecture description that is common in the
literature, particularly since much of the prior research on architecture excludes data as an
important architectural element. I concluded with a survey of other research related to
software architecture and architectural styles.
The next two chapters continue our discussion of background material by focusing on
network-based application architectures and describing how styles can be used to guide
their architectural design, followed by a survey of common architectural styles using a
classification methodology that highlights the architectural properties induced when the
styles are applied to an architecture for network-based hypermedia.23

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.
2.1.2 Application Software vs. Networking Software
Another restriction on the scope of this dissertation is that we limit our discussion to
application architectures, excluding the operating system, networking software, and some
architectural styles that would only use a network for system support (e.g., process control
styles [53]). Applications represent the “business-aware” functionality of a system [131].
Application software architecture is an abstraction level of an overall system, in which
the goals of a user action are representable as functional architectural properties. For
example, a hypermedia application must be concerned with the location of information
pages, performing requests, and rendering data streams. This is in contrast to a networking
abstraction, where the goal is to move bits from one location to another without regard to
why those bits are being moved. It is only at the application level that we can evaluate
design trade-offs based on the number of interactions per user action, the location of
application state, the effective throughput of all data streams (as opposed to the potential
throughput of a single data stream), the extent of communication being performed per user
action, etc.25

The evaluation of architectural properties within a tree of styles is specific to the needs
of a particular application domain because the impact of a given constraint is often
dependent on the application characteristics. For example, the pipe-and-filter style enables
several positive architectural properties when used within a system that requires data
transformations between components, whereas it would add nothing but overhead to a
system that consists only of control messages. Since it is rarely useful to compare
architectural designs across different application domains, the simplest means of ensuring
consistency is to make the tree domain-specific.
Design evaluation is frequently a question of choosing between trade-offs. Perry and
Wolf [105] describe a method of recognizing trade-offs explicitly by placing a numeric
weight against each property to indicate its relative importance to the architecture, thus
providing a normalized metric for comparing candidate designs. However, in order to be a
meaningful metric, each weight would have to be carefully chosen using an objective
scale that is consistent across all properties. In practice, no such scale exists. Rather than
having the architect fiddle with weight values until the result matches their intuition, I
prefer to present all of the information to the architect in a readily viewable form, and let
the architect’s intuition be guided by the visual pattern. This will be demonstrated in the
next chapter.
2.3 Architectural Properties of Key Interest
This section describes the architectural properties used to differentiate and classify
architectural styles in this dissertation. It is not intended to be a comprehensive list. I have
included only those properties that are clearly influenced by the restricted set of styles28

2.3.4.3 Customizability
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 [50]. Styles that support
customization may also improve simplicity and scalability, since service components can
be reduced in size and complexity by directly implementing only the most frequent
services and allowing infrequent services to be defined by the client. Customizability is a
property induced by the remote evaluation and code-on-demand styles.
2.3.4.4 Configurability
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. The pipe-and-filter and code-on-
demand styles are two examples that induce configurability of configurations and
components, respectively.
2.3.4.5 Reusability
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. The uniform pipe-and-filter style exemplifies these types of
constraints.35

2.4 Summary
This chapter examined the scope of the dissertation by focusing on network-based
application architectures and describing how styles can be used to guide their architectural
design. It also defined the set of architectural properties that will be used throughout the
rest of the dissertation for the comparison and evaluation of architectural styles.
The next chapter presents a survey of common architectural styles for network-based
application software within a classification framework that evaluates each style according
to the architectural properties it would induce if applied to an architecture for a
prototypical network-based hypermedia system.37

CHAPTER 3
Network-based Architectural Styles
This chapter presents a survey of common architectural styles for network-based
application software within a classification framework that evaluates each style according
to the architectural properties it would induce if applied to an architecture for a
prototypical network-based hypermedia system.
3.1 Classification Methodology
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. Therefore, in order to provide useful design
guidance, a classification of architectural styles should be based on the architectural
properties induced by those styles.
3.1.1 Selection of Architectural Styles for Classification
The set of architectural styles included in the classification is by no means comprehensive
of all possible network-based application styles. Indeed, a new style can be formed merely
by adding an architectural constraint to any one of the styles surveyed. My goal is to
describe a representative sample of styles, particularly those already identified within the
software architecture literature, and provide a framework by which other styles can be
added to the classification as they are developed.38

Focusing on a particular type of software allows us to identify the advantages of one style
over another in the same way that a designer of a system would evaluate those advantages.
Since we do not intend to declare any single style as being universally desirable for all
types of software, restricting the focus of our evaluation simply reduces the dimensions
over which we need to evaluate. Evaluating the same styles for other types of application
software is an open area for future research.
3.1.3 Visualization
I use a table of style versus architectural properties as the primary visualization for this
classification. The table values indicate the relative influence that the style for a given row
has on a column’s property. Minus (−) symbols accumulate for negative influences and
plus (+) symbols for positive, with plus-minus (±) indicating that it depends on some
aspect of the problem domain. Although this is a gross simplification of the details
presented in each section, it does indicate the degree to which a style has addressed (or
ignored) an architectural property.
An alternative visualization would be a property-based derivation graph for
classifying architectural styles. The styles would be classified according to how they are
derived from other styles, with the arcs between styles illustrated by architectural
properties gained or lost. The starting point of the graph would be the null style (no
constraints). It is possible to derive such a graph directly from the descriptions.40

allows independently developed filters to be arranged at will to form new applications. It
also simplifies the task of understanding how a given filter works.
A disadvantage of the uniform interface is that it may reduce network performance if
the data needs to be converted to or from its natural format.
3.3 Replication Styles
3.3.1 Replicated Repository (RR)
Systems based on the replicated repository style [6] improve the accessibility of data and
scalability of services by having more than one process provide the same service. These
decentralized servers interact to provide clients the illusion that there is just one,
centralized service. Distributed filesystems, such as XMS [49], and remote versioning
systems, like CVS [www.cyclic.com], are the primary examples.
Improved user-perceived performance is the primary advantage, both by reducing the
latency of normal requests and enabling disconnected operation in the face of primary
server failure or intentional roaming off the network. Simplicity remains neutral, since the
complexity of replication is offset by the savings of allowing network-unaware
components to operate transparently on locally replicated data. Maintaining consistency is
the primary concern.
Style Derivation Ne
t P
e
rfo
rm
.
UP

Pe
rfo
rm
.
Ef
fic
ie
n
cy
Sc
a
la
bi
lit
y
Si
m
pl
ic
ity
Ev
o
lva
bi
lit
y
Ex
te
ns
ib
ilit
y
Cu
st
o
m
iz
.
Co
n
fig
ur
.
R
eu
sa
bi
lit
y
Vi
si
bi
lit
y
Po
rta
bi
lit
y
R
e
lia
bi
lit
y
RR ++ + +
$ RR + + + +
Table 3-2. Evaluation of Replication Styles for Network-based Hypermedia43

3.4.6 Remote Session (RS)
The remote session style is a variant of client-server that attempts to minimize the
complexity, or maximize the reuse, of the client components rather than the server
component. Each client initiates a session on the server and then invokes a series of
services on the server, finally exiting the session. Application state is kept entirely on the
server. This style is typically used when it is desired to access a remote service using a
generic client (e.g., TELNET [106]) or via an interface that mimics a generic client (e.g.,
FTP [107]).
The advantages of the remote session style are that it is easier to centrally maintain the
interface at the server, reducing concerns about inconsistencies in deployed clients when
functionality is extended, and improves efficiency if the interactions make use of extended
session context on the server. The disadvantages are that it reduces scalability of the
server, due to the stored application state, and reduces visibility of interactions, since a
monitor would have to know the complete state of the server.
3.4.7 Remote Data Access (RDA)
The remote data access style [131] is a variant of client-server that spreads the application
state across both client and server. A client sends a database query in a standard format,
such as SQL, to a remote server. The server allocates a workspace and performs the query,
which may result in a very large data set. The client can then make further operations upon
the result set (such as table joins) or retrieve the result one piece at a time. The client must
know about the data structure of the service to build structure-dependent queries.49

The advantages of remote data access are that a large data set can be iteratively
reduced on the server side without transmitting it across the network, improving
efficiency, and visibility is improved by using a standard query language. The
disadvantages are that the client needs to understand the same database manipulation
concepts as the server implementation (lacking simplicity) and storing application context
on the server decreases scalability. Reliability also suffers, since partial failure can leave
the workspace in an unknown state. Transaction mechanisms (e.g., two-phase commit)
can be used to fix the reliability problem, though at a cost of added complexity and
interaction overhead.
3.5 Mobile Code Styles
Mobile code styles use mobility in order to dynamically change the distance between the
processing and source of data or destination of results. These styles are comprehensively
examined in Fuggetta et al. [50]. A site abstraction is introduced at the architectural level,
as part of the active configuration, in order to take into account the location of the different
components. Introducing the concept of location makes it possible to model the cost of an
interaction between components at the design level. In particular, an interaction between
components that share the same location is considered to have negligible cost when
compared to an interaction involving communication through the network. By changing
its location, a component may improve the proximity and quality of its interaction,
reducing interaction costs and thereby improving efficiency and user-perceived
performance.50

advantages of the LC$SS style. An example is the HotJava Web browser [java.sun.com],
which allows applets and protocol extensions to be downloaded as typed media.
The advantages and disadvantages of LCODC$SS are just a combination of those for
COD and LC$SS. We could go further and discuss the combination of COD with other CS
styles, but this survey is not intended to be exhaustive (nor exhausting).
3.5.5 Mobile Agent (MA)
In the mobile agent style [50], an entire computational component is moved to a remote
site, along with its state, the code it needs, and possibly some data required to perform the
task. This can be considered a derivation of the remote evaluation and code-on-demand
styles, since the mobility works both ways.
The primary advantage of the mobile agent style, beyond those already described for
REV and COD, is that there is greater dynamism in the selection of when to move the
code. An application can be in the midst of processing information at one location when it
decides to move to another location, presumably in order to reduce the distance between it
and the next set of data it wishes to process. In addition, the reliability problem of partial
failure is reduced because the application state is in one location at a time [50].54

dominated by data monitoring, rather than data retrieval, EBI can improve efficiency by
removing the need for polling interactions.
The basic form of EBI system consists of one event bus to which all components listen
for events of interest to them. Of course, this immediately leads to scalability issues with
regard to the number of notifications, event storms as other components broadcast as a
result of events caused by that notification, and a single point of failure in the notification
delivery system. This can be ameliorated though the use of layered systems and filtering
of events, at the cost of simplicity.
Other disadvantages of EBI systems are that it can be hard to anticipate what will
happen in response to an action (poor understandability) and event notifications are not
suitable for exchanging large-grain data [53]. Also, there is no support for recovery from
partial failure.
3.6.2 C2
The C2 architectural style [128] is directed at supporting large-grain reuse and flexible
composition of system components by enforcing substrate independence. It does so by
combining event-based integration with layered-client-server. Asynchronous notification
messages going down, and asynchronous request messages going up, are the sole means
of intercomponent communication. This enforces loose coupling of dependency on higher
layers (service requests may be ignored) and zero coupling with lower levels (no
knowledge of notification usage), improving control over the system without losing most
of the advantages of EBI.56

advantageous in terms of keeping the state where it is most likely to be up-to-date, but has
the disadvantage in that it is difficult to obtain an overall view of system activity (poor
visibility).
In order for one object to interact with another, it must know the identity of that other
object. When the identity of an object changes, it is necessary to modify all other objects
that explicitly invoke it [53]. There must be some controller object that is responsible for
maintaining the system state in order to complete the application requirements. Central
issues for distributed object systems include: object management, object interaction
management, and resource management [31].
Object systems are designed to isolate the data being processed. As a consequence,
data streaming is not supported in general. However, this does provide better support for
object mobility when combined with the mobile agent style.
3.6.4 Brokered Distributed Objects
In order to reduce the impact of identity, modern distributed object systems typically use
one or more intermediary styles to facilitate communication. This includes event-based
integration and brokered client/server [28]. The brokered distributed object style
introduces name resolver components whose purpose is to answer client object requests
for general service names with the specific name of an object that will satisfy the request.
Although improving reusability and evolvability, the extra level of indirection requires
additional network interactions, reducing efficiency and user-perceived performance.58

Brokered distributed object systems are currently dominated by the industrial
standards development of CORBA within the OMG [97] and the international standards
development of Open Distributed Processing (ODP) within ISO/IEC [66].
In spite of all the interest associated with distributed objects, they fare poorly when
compared to most other network-based architectural styles. They are best used for
applications that involve the remote invocation of encapsulated services, such as hardware
devices, where the efficiency and frequency of network interactions is less a concern.
3.7 Limitations
Each architectural style promotes a certain type of interaction among components. When
components are distributed across a wide-area network, use or misuse of the network
drives application usability. By characterizing styles by their influence on architectural
properties, and particularly on the network-based application performance of a distributed
hypermedia system, we gain the ability to better choose a software design that is
appropriate for the application. There are, however, a couple limitations with the chosen
classification.
The first limitation is that the evaluation is specific to the needs of distributed
hypermedia. For example, many of the good qualities of the pipe-and-filter style disappear
if the communication is fine-grained control messages, and are not applicable at all if the
communication requires user interactivity. Likewise, layered caching only adds to latency,
without any benefit, if none of the responses to client requests are cacheable. This type of
distinction does not appear in the classification, and is only addressed informally in the
discussion of each style. I believe this limitation can be overcome by creating separate59

Zimmer [137] organizes design patterns using a graph based on their relationships,
making it easier to understand the overall structure of the patterns in the Gamma et al. [51]
catalog. However, the patterns classified are not architectural patterns, and the
classification is based exclusively on derivation or uses relationships rather than on
architectural properties.
3.8.2 Distributed Systems and Programming Paradigms
Andrews [6] surveys how processes in a distributed program interact via message passing.
He defines concurrent programs, distributed programs, kinds of processes in a distributed
program (filters, clients, servers, peers), interaction paradigms, and communication
channels. Interaction paradigms represent the communication aspects of software
architectural styles. He describes paradigms for one-way data flow through networks of
filters (pipe-and-filter), client-server, heartbeat, probe/echo, broadcast, token passing,
replicated servers, and replicated workers with bag of tasks. However, the presentation is
from the perspective of multiple processes cooperating on a single task, rather than
general network-based architectural styles.
Sullivan and Notkin [126] provide a survey of implicit invocation research and
describe its application to improving the evolution quality of software tool suites. Barrett
et al. [8] present a survey of event-based integration mechanisms by building a framework
for comparison and then seeing how some systems fit within that framework. Rosenblum
and Wolf [114] investigate a design framework for Internet-scale event notification. All
are concerned with the scope and requirements of an EBI style, rather than providing
solutions for network-based systems.62

Fuggetta et al. [50] provide a thorough examination and classification of mobile code
paradigms. This chapter builds upon their work to the extent that I compare the mobile
code styles with other network-capable styles, and place them within a single framework
and set of architectural definitions.
3.8.3 Middleware
Bernstein [22] defines middleware as a distributed system service that includes standard
programming interfaces and protocols. These services are called middleware because they
act as a layer above the OS and networking software and below industry-specific
applications. Umar [131] presents an extensive treatment of the subject.
Architecture research regarding middleware focuses on the problems and effects of
integrating components with off-the-shelf middleware. Di Nitto and Rosenblum [38]
describe how the usage of middleware and predefined components can influence the
architecture of a system being developed and, conversely, how specific architectural
choices can constrain the selection of middleware. Dashofy et al. [35] discuss the use of
middleware with the C2 style.
Garlan et al. [56] point out some of the architectural assumptions within off-the-shelf
components, examining the authors’ problems with reusing subsystems in creating the
Aesop tool for architectural design [54]. They classify the problems into four main
categories of assumptions that can contribute to architectural mismatch: nature of
components, nature of connectors, global architectural structure, and construction process.63

CHAPTER 4
Designing the Web Architecture: Problems and Insights
This chapter presents the requirements of the World Wide Web architecture and the
problems faced in designing and evaluating proposed improvements to its key
communication protocols. I use the insights garnered from the survey and classification of
architectural styles for network-based hypermedia systems to hypothesize methods for
developing an architectural style that would be used to guide the design of improvements
for the modern Web architecture.
4.1 WWW Application Domain Requirements
Berners-Lee [20] writes that the “Web’s major goal was to be a shared information space
through which people and machines could communicate.” What was needed was a way
for people to store and structure their own information, whether permanent or ephemeral
in nature, such that it could be usable by themselves and others, and to be able to reference
and structure the information stored by others so that it would not be necessary for
everyone to keep and maintain local copies.
The intended end-users of this system were located around the world, at various
university and government high-energy physics research labs connected via the Internet.
Their machines were a heterogeneous collection of terminals, workstations, servers and
supercomputers, requiring a hodge podge of operating system software and file formats.
The information ranged from personal research notes to organizational phone listings. The
challenge was to build a system that would provide a universally consistent interface to66

this structured information, available on as many platforms as possible, and incrementally
deployable as new people and organizations joined the project.
4.1.1 Low Entry-barrier
Since participation in the creation and structuring of information was voluntary, a low
entry-barrier was necessary to enable sufficient adoption. This applied to all users of the
Web architecture: readers, authors, and application developers.
Hypermedia was chosen as the user interface because of its simplicity and generality:
the same interface can be used regardless of the information source, the flexibility of
hypermedia relationships (links) allows for unlimited structuring, and the direct
manipulation of links allows the complex relationships within the information to guide the
reader through an application. Since information within large databases is often much
easier to access via a search interface rather than browsing, the Web also incorporated the
ability to perform simple queries by providing user-entered data to a service and rendering
the result as hypermedia.
For authors, the primary requirement was that partial availability of the overall system
must not prevent the authoring of content. The hypertext authoring language needed to be
simple and capable of being created using existing editing tools. Authors were expected to
keep such things as personal research notes in this format, whether directly connected to
the Internet or not, so the fact that some referenced information was unavailable, either
temporarily or permanently, could not be allowed to prevent the reading and authoring of
information that was available. For similar reasons, it was necessary to be able to create
references to information before the target of that reference was available. Since authors67

were encouraged to collaborate in the development of information sources, references
needed to be easy to communicate, whether in the form of e-mail directions or written on
the back of a napkin at a conference.
Simplicity was also a goal for the sake of application developers. Since all of the
protocols were defined as text, communication could be viewed and interactively tested
using existing network tools. This enabled early adoption of the protocols to take place in
spite of the lack of standards.
4.1.2 Extensibility
While simplicity makes it possible to deploy an initial implementation of a distributed
system, extensibility allows us to avoid getting stuck forever with the limitations of what
was deployed. Even if it were possible to build a software system that perfectly matches
the requirements of its users, those requirements will change over time just as society
changes over time. A system intending to be as long-lived as the Web must be prepared
for change.
4.1.3 Distributed Hypermedia
Hypermedia is defined by the presence of application control information embedded
within, or as a layer above, the presentation of information. Distributed hypermedia allows
the presentation and control information to be stored at remote locations. By its nature,
user actions within a distributed hypermedia system require the transfer of large amounts
of data from where the data is stored to where it is used. Thus, the Web architecture must
be designed for large-grain data transfer.68

The usability of hypermedia interaction is highly sensitive to user-perceived latency:
the time between selecting a link and the rendering of a usable result. Since the Web’s
information sources are distributed across the global Internet, the architecture needs to
minimize network interactions (round-trips within the data transfer protocols).
4.1.4 Internet-scale
The Web is intended to be an Internet-scale distributed hypermedia system, which means
considerably more than just geographical dispersion. The Internet is about interconnecting
information networks across multiple organizational boundaries. Suppliers of information
services must be able to cope with the demands of anarchic scalability and the
independent deployment of software components.
4.1.4.1 Anarchic Scalability
Most software systems are created with the implicit assumption that the entire system is
under the control of one entity, or at least that all entities participating within a system are
acting towards a common goal and not at cross-purposes. Such an assumption cannot be
safely made when the system runs openly on the Internet. Anarchic scalability refers to the
need for architectural elements to continue operating when they are subjected to an
unanticipated load, or when given malformed or maliciously constructed data, since they
may be communicating with elements outside their organizational control. The
architecture must be amenable to mechanisms that enhance visibility and scalability.
The anarchic scalability requirement applies to all architectural elements. Clients
cannot be expected to maintain knowledge of all servers. Servers cannot be expected to
retain knowledge of state across requests. Hypermedia data elements cannot retain “back-69

deployment of architectural elements in a partial, iterative fashion, since it is not possible
to force deployment in an orderly manner.
4.2 Problem
In late 1993, it became clear that more than just researchers would be interested in the
Web. Adoption had occurred first in small research groups, spread to on-campus dorms,
clubs, and personal home pages, and later to the institutional departments for campus
information. When individuals began publishing their personal collections of information,
on whatever topics they might feel fanatic about, the social network-effect launched an
exponential growth of websites that continues today. Commercial interest in the Web was
just beginning, but it was clear by then that the ability to publish on an international scale
would be irresistible to businesses.
Although elated by its success, the Internet developer community became concerned
that the rapid growth in the Web’s usage, along with some poor network characteristics of
early HTTP, would quickly outpace the capacity of the Internet infrastructure and lead to a
general collapse. This was worsened by the changing nature of application interactions on
the Web. Whereas the initial protocols were designed for single request-response pairs,
new sites used an increasing number of in-line images as part of the content of Web pages,
resulting in a different interaction profile for browsing. The deployed architecture had
significant limitations in its support for extensibility, shared caching, and intermediaries,
which made it difficult to develop ad-hoc solutions to the growing problems. At the same
time, commercial competition within the software market led to an influx of new and
occasionally contradictory feature proposals for the Web’s protocols.71

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. This presented us
with a challenge: how do we introduce a new set of functionality to an architecture that is
already widely deployed, and how do we ensure that its introduction does not adversely
impact, or even destroy, the architectural properties that have enabled the Web to
succeed?
4.3 Approach
The early Web architecture was based on solid principles—separation of concerns,
simplicity, and generality—but lacked an architectural description and rationale. The
design was based on a set of informal hypertext notes [14], two early papers oriented
towards the user community [12, 13], and archived discussions on the Web developer
community mailing list (www-talk@info.cern.ch). In reality, however, the only true
description of the early Web architecture was found within the implementations of
libwww (the CERN protocol library for clients and servers), Mosaic (the NCSA browser
client), and an assortment of other implementations that interoperated with them.
An architectural style can be used to define the principles behind the Web architecture
such that they are visible to future architects. As discussed in Chapter 1, a style is a named
set of constraints on architectural elements that induces the set of properties desired of the72

Finally, the updated Web architecture, as defined by the revised protocol standards that
have been written according to the guidelines of the new architectural style, is deployed
through participation in the development of the infrastructure and middleware software
that make up the majority of Web applications. This included my direct participation in
software development for the Apache HTTP server project and the libwww-perl client
library, as well as indirect participation in other projects by advising the developers of the
W3C libwww and jigsaw projects, the Netscape Navigator, Lynx, and MSIE browsers,
and dozens of other implementations, as part of the IETF discourse.
Although I have described this approach as a single sequence, it is actually applied in a
non-sequential, iterative fashion. That is, over the past six years I have been constructing
models, adding constraints to the architectural style, and testing their affect on the Web’s
protocol standards via experimental extensions to client and server software. Likewise,
others have suggested the addition of features to the architecture that were outside the
scope of my then-current model style, but not in conflict with it, which resulted in going
back and revising the architectural constraints to better reflect the improved architecture.
The goal has always been to maintain a consistent and correct model of how I intend the
Web architecture to behave, so that it could be used to guide the protocol standards that
define appropriate behavior, rather than to create an artificial model that would be limited
to the constraints originally imagined when the work began.
Hypothesis III: Proposals to modify the Web architecture can be
compared to the updated WWW architectural style and analyzed for
conflicts prior to deployment.74

CHAPTER 5
Representational State Transfer (REST)
This chapter introduces and elaborates the Representational State Transfer (REST)
architectural style for distributed hypermedia systems, describing the software engineering
principles guiding REST and the interaction constraints chosen to retain those principles,
while contrasting them to the constraints of other architectural styles. REST is a hybrid
style derived from several of the network-based architectural styles described in Chapter 3
and combined with additional constraints that define a uniform connector interface. The
software architecture framework of Chapter 1 is used to define the architectural elements
of REST and examine sample process, connector, and data views of prototypical
architectures.
5.1 Deriving REST
The design rationale behind the Web architecture can be described by an architectural
style consisting of the set of constraints applied to elements within the architecture. By
examining the impact of each constraint as it is added to the evolving style, we can
identify the properties induced by the Web’s constraints. Additional constraints can then
be applied to form a new architectural style that better reflects the desired properties of a
modern Web architecture. This section provides a general overview of REST by walking
through the process of deriving it as an architectural style. Later sections will describe in
more detail the specific constraints that compose the REST style.76

5.1.1 Starting with the Null Style
There are two common perspectives on the process of architectural design, whether it be
for buildings or for software. The first is that a designer starts with nothing—a blank slate,
whiteboard, or drawing board—and builds-up an architecture from familiar components
until it satisfies the needs of the intended system. The second is that a designer starts with
the system needs as a whole, without constraints, and then incrementally identifies and
applies constraints to elements of the system in order to differentiate the design space and
allow the forces that influence system behavior to flow naturally, in harmony with the
system. Where the first emphasizes creativity and unbounded vision, the second
emphasizes restraint and understanding of the system context. REST has been developed
using the latter process. Figures 5-1 through 5-8 depict this graphically in terms of how the
applied constraints would differentiate the process view of an architecture as the
incremental set of constraints is applied.
The Null style (Figure 5-1) is simply an empty set of constraints. From an architectural
perspective, the null style describes a system in which there are no distinguished
boundaries between components. It is the starting point for our description of REST.
Figure 5-1. Null Style
WWW77

5.1.2 Client-Server
The first constraints added to our hybrid style are those of the client-server architectural
style (Figure 5-2), described in Section 3.4.1. Separation of concerns is the principle
behind the client-server constraints. By separating the user interface concerns from the
data storage concerns, we improve the portability of the user interface across multiple
platforms and improve scalability by simplifying the server components. Perhaps most
significant to the Web, however, is that the separation allows the components to evolve
independently, thus supporting the Internet-scale requirement of multiple organizational
domains.
5.1.3 Stateless
We next add a constraint to the client-server interaction: communication must be stateless
in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such
that each request from client to server must contain all of the information necessary to
Figure 5-2. Client-Server
Client Server
Figure 5-3. Client-Stateless-Server
Client Server78

The advantage of adding cache constraints is that they have the potential to partially or
completely eliminate some interactions, improving efficiency, scalability, and user-
perceived performance by reducing the average latency of a series of interactions. The
trade-off, however, is that a cache can decrease reliability if stale data within the cache
differs significantly from the data that would have been obtained had the request been sent
directly to the server.
The early Web architecture, as portrayed by the diagram in Figure 5-5 [11], was
defined by the client-cache-stateless-server set of constraints. That is, the design rationale
presented for the Web architecture prior to 1994 focused on stateless client-server
interaction for the exchange of static documents over the Internet. The protocols for
communicating interactions had rudimentary support for non-shared caches, but did not
constrain the interface to a consistent set of semantics for all resources. Instead, the Web
relied on the use of a common client-server implementation library (CERN libwww) to
maintain consistency across Web applications.
Developers of Web implementations had already exceeded the early design. In
addition to static documents, requests could identify services that dynamically generated
responses, such as image-maps [Kevin Hughes] and server-side scripts [Rob McCool].
Figure 5-4. Client-Cache-Stateless-Server
Client Server
$
$
Client+Cache80

Work had also begun on intermediary components, in the form of proxies [79] and shared
caches [59], but extensions to the protocols were needed in order for them to communicate
reliably. The following sections describe the constraints added to the Web’s architectural
style in order to guide the extensions that form the modern Web architecture.
5.1.5 Uniform Interface
The central feature that distinguishes the REST architectural style from other network-
based styles is its emphasis on a uniform interface between components (Figure 5-6). By
applying the software engineering principle of generality to the component interface, the
overall system architecture is simplified and the visibility of interactions is improved.
Implementations are decoupled from the services they provide, which encourages
dumb PC Mac X NeXT
HTTP
server
FTP
server
NNTP
server
Internet
News
VM
S H
elp gatew
a
XF
IND gateway
WA
IS gateway
Addressing scheme + Common protocol + Format negotiation
Browsers
Servers/Gateways
Gopher
server
© 1992 Tim Berners-Lee, Robert Cailliau, Jean-François Groff, C.E.R.N.
Figure 5-5. Early WWW Architecture Diagram81

independent evolvability. The trade-off, though, is that a uniform interface degrades
efficiency, since information is transferred in a standardized form rather than one which is
specific to an application’s needs. 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.
In order to obtain a uniform interface, multiple architectural constraints are needed to
guide the behavior of components. 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. These
constraints will be discussed in Section 5.2.
5.1.6 Layered System
In order to further improve behavior for Internet-scale requirements, we add layered
system constraints (Figure 5-7). As described in Section 3.4.2, the layered system style
allows an architecture to be composed of hierarchical layers by constraining component
behavior such that each component cannot “see” beyond the immediate layer with which
Figure 5-6. Uniform-Client-Cache-Stateless-Server
orb
$ $Client+Cache:Client Connector: Server Connector: Server+Cache:
$
$
$82