roy thomas fielding dissertation pdf

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

Roy Thomas Fielding

Dissertation Committee: Professor Richard N. Taylor, Chair Professor Mark S. Ackerman Professor David S. Rosenblum © Roy Thomas Fielding, 2000. All rights reserved.

2000 DEDICATION

To my parents,

Pete and Kathleen Fielding,

The dissertation of Roy Thomas Fielding is approved and is acceptable in quality and form who made all of this possible, for publication on microfilm: 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. ______Committee Chair 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 University of California, Irvine stretched out in the long grass of a meadow. 2000 — Christopher Alexander, The Timeless Way of Building (1979)

ii iii TABLE OF CONTENTS

Page CHAPTER 3: Network-based Architectural Styles ...... 38 3.1 Classification Methodology...... 38 LIST OF FIGURES ...... vi 3.2 Data-flow Styles ...... 41 3.3 Replication Styles ...... 43 3.4 Hierarchical Styles...... 45 LIST OF TABLES...... vii 3.5 Mobile Code Styles...... 50 3.6 Peer-to-Peer Styles...... 55 ACKNOWLEDGMENTS ...... viii 3.7 Limitations ...... 59 3.8 Related Work ...... 60 3.9 Summary...... 64 CURRICULUM VITAE...... x CHAPTER 4: Designing the Web Architecture: Problems and Insights...... 66 ABSTRACT OF THE DISSERTATION ...... xvi 4.1 WWW Application Domain Requirements ...... 66 4.2 Problem...... 71 INTRODUCTION ...... 1 4.3 Approach...... 72 4.4 Summary...... 75 CHAPTER 1: Software Architecture ...... 5 CHAPTER 5: Representational State Transfer (REST)...... 76 1.1 Run-time Abstraction...... 5 1.2 Elements...... 7 5.1 Deriving REST ...... 76 1.3 Configurations ...... 12 5.2 REST Architectural Elements...... 86 1.4 Properties ...... 12 5.3 REST Architectural Views ...... 97 1.5 Styles...... 13 5.4 Related Work ...... 103 1.6 Patterns and Pattern Languages ...... 16 5.5 Summary...... 105 1.7 Views ...... 17 1.8 Related Work ...... 18 CHAPTER 6: Experience and Evaluation ...... 107 1.9 Summary...... 23 6.1 Standardizing the Web...... 107 6.2 REST Applied to URI...... 109 CHAPTER 2: Network-based Application Architectures...... 24 6.3 REST Applied to HTTP...... 116 2.1 Scope...... 24 6.4 Technology Transfer...... 134 2.2 Evaluating the Design of Application Architectures ...... 26 6.5 Architectural Lessons ...... 138 2.3 Architectural Properties of Key Interest ...... 28 6.6 Summary...... 147 2.4 Summary...... 37 CONCLUSIONS...... 148

REFERENCES...... 152

iv v LIST OF FIGURES LIST OF TABLES

Figure 5-1. Null Style 77 Table 3-1. Evaluation of Data-flow Styles for Network-based Hypermedia 41

Figure 5-2. Client-Server 78 Table 3-2. Evaluation of Replication Styles for Network-based Hypermedia 43

Figure 5-3. Client-Stateless-Server 78 Table 3-3. Evaluation of Hierarchical Styles for Network-based Hypermedia 45

Figure 5-4. Client-Cache-Stateless-Server 80 Table 3-4. Evaluation of Mobile Code Styles for Network-based Hypermedia 51

Figure 5-5. Early WWW Architecture Diagram 81 Table 3-5. Evaluation of Peer-to-Peer Styles for Network-based Hypermedia 55

Figure 5-6. Uniform-Client-Cache-Stateless-Server 82 Table 3-6. Evaluation Summary 65

Figure 5-7. Uniform-Layered-Client-Cache-Stateless-Server 83 Table 5-1. REST Data Elements 88

Figure 5-8. REST 84 Table 5-2. REST Connectors 93

Figure 5-9. REST Derivation by Style Constraints 85 Table 5-3. REST Components 96

Figure 5-10. Process View of a REST-based Architecture 98

vi vii 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 The modern Web architecture is still defined more by the work of individual volunteers Dick Taylor, my long-time advisor and committee chair. Mark Ackerman also deserves a than by any single company. Chief among them are the members of the Apache Software great deal of thanks, for it was his class on distributed information services in 1993 that Foundation. Special thanks go to Robert S. Thau for the incredibly robust Shambhala introduced me to the Web developer community and led to all of the design work design that led to Apache 1.0, as well as for many discussions on desirable (and described in this dissertation. Likewise, it was David Rosenblum’s work on Internet-scale undesirable) Web extensions, to Dean Gaudet for teaching me more about detailed system software architectures that convinced me to think of my own research in terms of performance evaluation than I thought I needed to know, and to Alexei Kosut for being the architecture, rather than simply hypermedia or application-layer protocol design. first to implement most of HTTP/1.1 in Apache. Additional thanks to the rest of the Apache Group founders, including Brian Behlendorf, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, and Andrew Wilson, for building a community that we The Web’s architectural style was developed iteratively over a six year period, but can all be proud of and changing the world one more time. 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 I’d also like to thank all of the people at eBuilt who have made it such a great place to Taskforce (IETF). I would particularly like to thank Tim Berners-Lee, Henrik Frystyk work. Particular thanks go to the four technical founders — Joe Lindsay, Phil Lindsay, Nielsen, Dan Connolly, Dave Raggett, Rohit Khare, Jim Whitehead, Larry Masinter, and Jim Hayes, and Joe Manna — for creating (and defending) a culture that makes Dan LaLiberte for many thoughtful conversations regarding the nature and goals of the engineering fun. Thanks also to Mike Dewey, Jeff Lenardson, Charlie Bunten, and WWW architecture. I’d also like to thank Ken Anderson for his insight into the open Ted Lavoie, for making it possible to earn money while having fun. And special thanks to hypertext community and for trailblazing the path for hypermedia research at UCI. Thanks Linda Dailing, for being the glue that holds us all together. also to my fellow architecture researchers at UCI, all of whom finished before me, including Peyman Oreizy, NenoMedvidovic, JasonRobbins, and David Hilbert. Thanks and good luck go out to the team at Endeavors Technology, including Greg Bolcer, Clay Cover, Art Hitomi, and Peter Kammer. Finally, I’d like to thank my The Web architecture is based on the collaborative work of dozens of volunteer software three muses—Laura, Nikki, and Ling—for their inspiration while writing this dissertation. 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, In large part, my dissertation research has been sponsored by the Defense Advanced recognition should go to the server developers that enabled much of the Web’s rapid Research Projects Agency, and Airforce Research Laboratory, Air Force Materiel growth in 1993-1994 (more so, I believe, than did the browsers). That includes Command, USAF, under agreement number F30602-97-2-0021. The U.S. Government is Rob McCool (NCSA httpd), Ari Luotonen (CERN httpd/proxy), and Tony Sanders authorized to reproduce and distribute reprints for Governmental purposes (Plexus). Thanks also to “Mr. Content”, Kevin Hughes, for being the first to implement notwithstanding any copyright annotation thereon. The views and conclusions contained most of the interesting ways to show information on the Web beyond hypertext. The early herein are those of the authors and should not be interpreted as necessarily representing client developers also deserve thanks: Nicola Pellow (line-mode), Pei Wei (Viola), the official policies or endorsements, either expressed or implied, of the Defense Tony Johnson (Midas), Lou Montulli (Lynx), Bill Perry (W3), and Marc Andreessen and Advanced Research Projects Agency, Airforce Research Laboratory or the U.S. Eric Bina (Mosaic for X). Finally, my personal thanks go to my libwww -perl Government. collaborators, Oscar Nierstrasz, Martijn Koster, and Gisle Aas. Cheers!

viii ix CURRICULUM VITAE Publications Refereed Journal Articles Roy Thomas Fielding [1] R. T. Fielding, E. J. Whitehead, Jr., K. M. Anderson, G. A. Bolcer, P. Oreizy, and R. N. Taylor. Web-based Development of Complex Information Products. Education Communications of the ACM, 41(8), August 1998, pp. 84-92. Doctor of Philosophy (2000) [2] R. T. Fielding. Maintaining Distributed Hypertext Infostructures: Welcome to University of California, Irvine MOMspider’s Web. Computer Networks and ISDN Systems, 27(2), November 1994, Information and Computer Science pp. 193-204. (Revision of [7] after special selection by referees.) Institute of Software Research Advisor: Dr. Richard N. Taylor Refereed Conference Publications Dissertation: Architectural Styles and the Design of Network-based Software Architectures [3] R. T. Fielding and R. N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 2000 International Conference on Software Engineering Master of Science (1993) (ICSE 2000), Limerick, Ireland, June 2000, pp. 407-416. University of California, Irvine Information and Computer Science [4] A. Mockus, R. T. Fielding, and J. Herbsleb. A Case Study of Open Source Software Major Emphasis: Software Development: The Apache Server. In Proceedings of the 2000 International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. Bachelor of Science (1988) 263-272. University of California, Irvine Information and Computer Science [5] E. J. Whitehead, Jr., R. T. Fielding, and K. M. Anderson. Fusing WWW and Link Server Technology: One Approach. In Proceedings of the 2nd Workshop on Open Hypermedia Systems, Hypertext’96, Washington, DC, March, 1996, pp. 81-86. Professional Experience [6] M. S. Ackerman and R. T. Fielding. Collection Maintenance in the Digital Library. 12/99 - Chief Scientist, eBuilt, Inc., Irvine, California In Proceedings of Digital Libraries ’95, Austin, Texas, June 1995, pp. 39-48. 3/99 - Chairman, The Apache Software Foundation [7] R. T. Fielding. Maintaining Distributed Hypertext Infostructures: Welcome to 4/92 - 12/99 Graduate Student Researcher, Institute for Software Research MOMspider’s Web. In Proceedings of the First International World Wide Web University of California, Irvine Conference, Geneva, Switzerland, May 1994, pp. 147-156. 6/95 - 9/95 Visiting Scholar, World Wide Web Consortium (W3C) Industry Standards MIT Laboratory of Computer Science, Cambridge, Massachusetts [8] R. T. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, L. Masinter, P. Leach, and 9/91 - 3/92 Teaching Assistant T. Berners-Lee. Hypertext Transfer Protocol — HTTP/1.1. Internet Draft Standard ICS 121 - Introduction to Software Engineering RFC 2616, June 1999. [Obsoletes RFC 2068, January 1997.] ICS 125A - Project in Software Engineering University of California, Irvine [9] T. Berners-Lee, R. T. Fielding, and L. Masinter. Uniform Resource Identifiers 11/89 - 6/91 Software Engineer (URI): Generic Syntax. Internet Draft Standard RFC 2396, August 1998. ADC Kentrox, Inc., Portland, Oregon [10] J. Mogul, R. T. Fielding, J. Gettys, and H. F. Frystyk. Use and Interpretation of 7/88 - 8/89 Professional Staff (Software Engineer) HTTP Version Numbers. Internet Informational RFC 2145, May 1997. PRC Public Management Services, Inc., San Francisco, California [11] T. Berners-Lee, R. T. Fielding, and H. F. Nielsen. Hypertext Transfer Protocol — 10/86 - 6/88 Programmer/Analyst HTTP/1.0. Internet Informational RFC 1945, May 1996. Megadyne Information Systems, Inc., Santa Ana, California [12] R. T. Fielding. Relative Uniform Resource Locators. Internet Proposed Standard 6/84 - 9/86 Programmer/Analyst RFC 1808, June 1995. TRANSMAX, Inc., Santa Ana, California

x xi Industry Articles [4] Human Communication and the Design of the Modern Web Architecture. WebNet World Conference on the WWW and the Internet (WebNet 99), Honolulu, HI, [13] R. T. Fielding. The Secrets to Apache’s Success. Linux Magazine, 1(2), June 1999, October 1999. pp. 29-71. [5] The Apache Software Foundation. Computer & Communications Industry [14] R. T. Fielding. Shared Leadership in the Apache Project. Communications of the Association, Autumn Members Meeting, Dallas, TX, September 1999. ACM, 42(4), April 1999, pp. 42-43. [6] Uniform Resource Identifiers. The Workshop on Internet-scale Technology [15] R. T. Fielding and G. E. Kaiser. The Apache HTTP Server Project. IEEE Internet (TWIST 99), Irvine, CA, August 1999. Computing, 1(4), July-August 1997, pp. 88-90. [7] Apache: Past, Present, and Future. Web Design World, Seattle, WA, July 1999. Non-Refereed Publications [8] Progress Report on Apache. ZD Open Source Forum, Austin, TX, June 1999. [16] R. T. Fielding. Architectural Styles for Network-based Applications. Phase II [9] Open Source, Apache-style: Lessons Learned from Collaborative Software Survey Paper, Department of Information and Computer Science, University of Development. Second Open Source and Community Licensing Summit, San Jose, California, Irvine, July 1999. CA, March 1999. [17] J. Grudin and R. T. Fielding. Working Group on Design Methods and Processes. In [10] The Apache HTTP Server Project: Lessons Learned from Collaborative Software. Proceedings of the ICSE’94 Workshop on SE-HCI: Joint Research Issues, Sorrento, AT&T Labs — Research, Folsom Park, NJ, October 1998. Italy, May 1994. Published in “Software Engineering and Human-Computer [11] Collaborative Software Development: Joining the Apache Project. ApacheCon ‘98, Interaction,” Springer-Verlag LNCS, vol. 896, 1995, pp. 4-8. San Francisco, CA, October 1998. Published on the [18] R. T. Fielding. Conditional GET Proposal for HTTP Caching. [12] Representational State Transfer: An Architectural Style for Distributed Hypermedia WWW , January 1994. Interaction. Microsoft Research, Redmond, WA, May 1998. Published Software Packages [13] The Apache Group: A Case Study of Internet Collaboration and Virtual Communities. UC Irvine Social Sciences WWW Seminar, Irvine, CA, May 1997. [19] Apache httpd. The Apache HTTP server is the world's most popular Web server software, used by more than 65% of all public Internet sites as of July 2000. [14] WebSoft: Building a Global Software Engineering Environment. Workshop on Software Engineering (on) the World Wide Web, 1997 International Conference on [20] libwww-perl. A library of Perl4 packages that provides a simple and consistent Software Engineering (ICSE 97), Boston, MA, May 1997. programming interface to the World Wide Web. [15] Evolution of the Hypertext Transfer Protocol. ICS Research Symposium, Irvine, [21] Onions. A library of Ada95 packages that provides an efficient stackable streams CA, January 1997. capability for network and file system I/O. [16] World Wide Web Infrastructure and Evolution. IRUS SETT Symposium on [22] MOMspider. MOMspider is a web robot for providing multi-owner maintenance of WIRED: World Wide Web and the Internet, Irvine, CA, May 1996. distributed hypertext infostructures. [17] HTTP Caching. Fifth International World Wide Web Conference (WWW5), Paris, [23] wwwstat. A set of utilities for searching and summarizing WWW httpd server access France, May 1996. logs and assisting other webmaster tasks. [18] The Importance of World Wide Web Infrastructure. California Software Symposium (CSS ‘96), Los Angeles, CA, April 1996. Formal Presentations [19] World Wide Web Software: An Insider’s View. IRUS Bay Area Roundtable (BART), [1] State of Apache. O’Reilly Open Source Software Convention, Monterey, CA, July Palo Alto, CA, January 1996. 2000. [20] libwww-Perl4 and libwww-Ada95. Fourth International World Wide Web [2] Principled Design of the Modern Web Architecture. 2000 International Conference Conference, Boston, MA, December 1995. on Software Engineering, Limerick, Ireland, June 2000. [21] Hypertext Transfer Protocol — HTTP/1.x. Fourth International World Wide Web [3] HTTP and Apache. ApacheCon 2000, Orlando, FL, March 2000. Conference, Boston, MA, December 1995.

xii xiii [22] Hypertext Transfer Protocol — HTTP/1.x. HTTP Working Group, 34th Internet Honors, Awards, Fellowships Engineering Taskforce Meeting, Dallas, TX, December 1995. 2000 Appaloosa Award for Vision, O’Reilly Open Source 2000 [23] Hypertext Transfer Protocol — HTTP/1.0 and HTTP/1.1. HTTP Working Group, 32nd Internet Engineering Taskforce Meeting, Danvers, MA, April 1995. 2000 Outstanding Graduate Student, UCI Alumni Association [24] WWW Developer Starter Kits for Perl. WebWorld Conference, Orlando, FL, 1999 ACM Software System Award January 1995, and Santa Clara, CA, April 1995. 1999 TR100: Top 100 young innovators, MIT Technology Review [25] Relative Uniform Resource Locators. URI Working Group, 31st Internet 1991 Regent’s Fellowship, University of California Engineering Taskforce Meeting, San Jose, CA, December 1994. 1988 Golden Key National Honor Society [26] Hypertext Transfer Protocol — HTTP/1.0. HTTP BOF, 31st Internet Engineering 1987 Dean’s Honor List 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 xv ABSTRACT OF THE DISSERTATION 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 Architectural Styles and the Design of Network-based Software Architectures network-based applications is used to classify styles according to the architectural by properties they induce on an architecture for distributed hypermedia. I then introduce the Roy Thomas Fielding Representational State Transfer (REST) architectural style and describe how REST has Doctor of Philosophy in Information and Computer Science been used to guide the design and development of the architecture for the modern Web. University of California, Irvine, 2000 REST emphasizes scalability of component interactions, generality of interfaces, Professor Richard N. Taylor, Chair independent deployment of components, and intermediary components to reduce

interaction latency, enforce security, and encapsulate legacy systems. I describe the The World Wide Web has succeeded in large part because its software architecture has software engineering principles guiding REST and the interaction constraints chosen to been designed to meet the needs of an Internet-scale distributed hypermedia system. The retain those principles, contrasting them to the constraints of other architectural styles. Web has been iteratively developed over the past ten years through a series of Finally, I describe the lessons learned from applying REST to the design of the Hypertext modifications to the standards that define its architecture. In order to identify those aspects Transfer Protocol and Uniform Resource Identifier standards, and from their subsequent of the Web that needed improvement and avoid undesirable modifications, a model for the deployment in Web client and server software. modern Web architecture was needed to guide its design, definition, and deployment.

Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how elements of a system can evolve independently, and how all of the above can be described using formal and informal notations. 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. An architectural style is a named, coordinated set of architectural constraints.

xvi xvii INTRODUCTION 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. Excuse me ... did you say ‘knives’? — City Gent #1 (Michael Palin), The Architects Sketch [111] 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 As predicted by Perry and Wolf [105], software architecture has been a focal point for constraints is useful. In other words, the reasoning behind good software architectures is software engineering research in the 1990s. The complexity of modern software systems not apparent to designers when those architectures are selected for reuse. have necessitated a greater emphasis on componentized systems, where the This dissertation explores a junction on the frontiers of two research disciplines in implementation is partitioned into independent components that communicate to perform computer science: software and networking. Software research has long been concerned a desired task. Software architecture research investigates methods for determining how with the categorization of software designs and the development of design methodologies, best to partition a system, how components identify and communicate with each other, but has rarely been able to objectively evaluate the impact of various design choices on how information is communicated, how elements of a system can evolve independently, system behavior. Networking research, in contrast, is focused on the details of generic and how all of the above can be described using formal and informal notations. communication behavior between systems and improving the performance of particular A good architecture is not created in a vacuum. All design decisions at the communication techniques, often ignoring the fact that changing the interaction style of an architectural level should be made within the context of the functional, behavioral, and application can have more impact on performance than the communication protocols used social requirements of the system being designed, which is a principle that applies equally for that interaction. My work is motivated by the desire to understand and evaluate the to both software architecture and the traditional field of building architecture. The architectural design of network-based application software through principled use of guideline that “form follows function” comes from hundreds of years of experience with architectural constraints, thereby obtaining the functional, performance, and social failed building projects, but is often ignored by software practitioners. The funny bit properties desired of an architecture. When given a name, a coordinated set of within the Monty Python sketch, cited above, is the absurd notion that an architect, when architectural constraints becomes an architectural style. faced with the goal of designing an urban block of flats (apartments), would present a The first three chapters of this dissertation define a framework for understanding building design with all the components of a modern slaughterhouse. It might very well be software architecture via architectural styles, revealing how styles can be used to guide the the best slaughterhouse design ever conceived, but that would be of little comfort to the architectural design of network-based application software. Common architectural styles prospective tenants as they are whisked along hallways containing rotating knives.

1 2 are surveyed and classified according to the architectural properties they induce when Over the past six years, the REST architectural style has been used to guide the design applied to an architecture for network-based hypermedia. This classification is used to and development of the architecture for the modern Web, as presented in Chapter 6. This identify a set of architectural constraints that could be used to improve the architecture of work was done in conjunction with my authoring of the Internet standards for the the early World Wide Web. Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI), the two

Architecting the Web requires an understanding of its requirements, as we shall specifications that define the generic interface used by all component interactions on the discuss in Chapter 4. The Web is intended to be an Internet-scale distributed hypermedia Web. system, which means considerably more than just geographical dispersion. The Internet is Like most real-world systems, not all components of the deployed Web architecture about interconnecting information networks across organizational boundaries. Suppliers obey every constraint present in its architectural design. REST has been used both as a of information services must be able to cope with the demands of anarchic scalability and means to define architectural improvements and to identify architectural mismatches. the independent deployment of software components. Distributed hypermedia provides a Mismatches occur when, due to ignorance or oversight, a software implementation is uniform means of accessing services through the embedding of action controls within the deployed that violates the architectural constraints. While mismatches cannot be avoided presentation of information retrieved from remote sites. An architecture for the Web must in general, it is possible to identify them before they become standardized. Several therefore be designed with the context of communicating large-grain data objects across mismatches within the modern Web architecture are summarized in Chapter 6, along with high-latency networks and multiple trust boundaries. analyses of why they arose and how they deviate from REST.

Chapter 5 introduces and elaborates the Representational State Transfer (REST) In summary, this dissertation makes the following contributions to software research architectural style for distributed hypermedia systems. REST provides a set of within the field of Information and Computer Science: architectural constraints that, when applied as a whole, emphasizes scalability of • a framework for understanding software architecture through architectural styles, including a consistent set of terminology for describing software architecture; component interactions, generality of interfaces, independent deployment of components, • a classification of architectural styles for network-based application software by and intermediary components to reduce interaction latency, enforce security, and the architectural properties they would induce when applied to the architecture for a distributed hypermedia system; encapsulate legacy systems. I describe the software engineering principles guiding REST • REST, a novel architectural style for distributed hypermedia systems; and, and the interaction constraints chosen to retain those principles, contrasting them to the • application and evaluation of the REST architectural style in the design and constraints of other architectural styles. deployment of the architecture for the modern World Wide Web.

3 4 CHAPTER 1 by the parent element’s abstract interface. This recursion of architectures continues down Software Architecture 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 In spite of the interest in software architecture as a field of research, there is little operational phases, such as start-up, initialization, normal processing, re-initialization, and agreement among researchers as to what exactly should be included in the definition of shutdown. Each operational phase has its own architecture. For example, a configuration architecture. In many cases, this has led to important aspects of architectural design being file will be treated as a data element during the start-up phase, but won’t be considered an overlooked by past research. This chapter defines a self-consistent terminology for architectural element during normal processing, since at that point the information it software architecture based on an examination of existing definitions within the literature contained will have already been distributed throughout the system. It may, in fact, have and my own insight with respect to network-based application architectures. Each defined the normal processing architecture. An overall description of a system architecture definition, highlighted within a box for ease of reference, is followed by a discussion of must be capable of describing not only the operational behavior of the system’s how it is derived from, or compares to, related research. architecture during each phase, but also the architecture of transitions between phases.

1.1 Run-time Abstraction Perry and Wolf [105] define processing elements as “transformers of data,” while

A software architecture is an abstraction of the run-time elements of a Shaw et al. [118] describe components as “the locus of computation and state.” This is software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, further clarified in Shaw and Clements [122]: “A component is a unit of software that each with its own software architecture. performs some function at run-time. Examples include programs, objects, processes, and

At the heart of software architecture is the principle of abstraction: hiding some of the filters.” This raises an important distinction between software architecture and what is details of a system through encapsulation in order to better identify and sustain its typically referred to as software structure: the former is an abstraction of the run-time properties [117]. A complex system will contain many levels of abstraction, each with its behavior of a software system, whereas the latter is a property of the static software source own architecture. An architecture represents an abstraction of system behavior at that code. Although there are advantages to having the modular structure of the source code level, such that architectural elements are delineated by the abstract interfaces they match the decomposition of behavior within a running system, there are also advantages to provide to other elements at that level [9]. Within each element may be found another having independent software components be implemented using parts of the same code architecture, defining the system of sub-elements that implement the behavior represented (e.g., shared libraries). We separate the view of software architecture from that of the

5 6 source code in order to focus on the software’s run-time characteristics independent of a past performance to change future behavior, but in doing so they are replacing one lower- given component’s implementation. Therefore, architectural design and source code level architecture with another lower-level architecture, rather than encompassing structural design, though closely related, are separate design activities. Unfortunately, rationale within those architectures. some descriptions of software architecture fail to make this distinction (e.g., [9]). As an illustration, consider what happens to a building if its blueprints and design

plans are burned. Does the building immediately collapse? No, since the properties by 1.2 Elements which the walls sustain the weight of the roof remain intact. An architecture has, by

A software architecture is defined by a configuration of architectural design, a set of properties that allow it to meet or exceed the system requirements. elements—components, connectors, and data—constrained in their relationships in order to achieve a desired set of architectural properties. Ignorance of those properties may lead to later changes which violate the architecture, just

A comprehensive examination of the scope and intellectual basis for software architecture as the replacement of a load-bearing wall with a large window frame may violate the can be found in Perry and Wolf [105]. They present a model that defines a software structural stability of a building. Thus, instead of rationale, our definition of software architecture as a set of architectural elements that have a particular form, explicated by a architecture includes architectural properties. Rationale explicates those properties, and set of rationale. Architectural elements include processing, data, and connecting elements. lack of rationale may result in gradual decay or degradation of the architecture over time,

Form is defined by the properties of the elements and the relationships among the but the rationale itself is not part of the architecture. elements — that is, the constraints on the elements. The rationale provides the underlying A key feature of the model in Perry and Wolf [105] is the distinction of the various Processing elements data basis for the architecture by capturing the motivation for the choice of architectural style, element types. are those that perform transformations on data, elements the choice of elements, and the form. are those that contain the information that is used and transformed, and connecting elements My definitions for software architecture are an elaborated version of those within the are the glue that holds the different pieces of the architecture components connectors Perry and Wolf [105] model, except that I exclude rationale. Although rationale is an together. I use the more prevalent terms of and to refer to important aspect of software architecture research and of architectural description in processing and connecting elements, respectively. particular, including it within the definition of software architecture would imply that Garlan and Shaw [53] describe an architecture of a system as a collection of design documentation is part of the run-time system. The presence or absence of rationale computational components together with a description of the interactions between these can influence the evolution of an architecture, but, once constituted, the architecture is components—the connectors. This model is expanded upon in Shaw et al. [118]: The independent of its reasons for being. Reflective systems [80] can use the characteristics of architecture of a software system defines that system in terms of components and of

7 8 interactions among those components. In addition to specifying the structure and topology loading into memory from secondary storage, performing some calculation, translating to of the system, the architecture shows the intended correspondence between the system a different format, encapsulation with other data, etc. The behavior of each component is requirements and elements of the constructed system. Further elaboration of this definition part of the architecture insofar as that behavior can be observed or discerned from the can be found in Shaw and Garlan [121]. point of view of another component [9]. In other words, a component is defined by its

What is surprising about the Shaw et al. [118] model is that, rather than defining the interface and the services it provides to other components, rather than by its software’s architecture as existing within the software, it is defining a description of the implementation behind the interface. Parnas [101] would define this as the set of software’s architecture as if that were the architecture. In the process, software assumptions that other architectural elements can make about the component. architecture as a whole is reduced to what is commonly found in most informal 1.2.2 Connectors architecture diagrams: boxes (components) and lines (connectors). Data elements, along A connector is an abstract mechanism that mediates communication, with many of the dynamic aspects of real software architectures, are ignored. Such a coordination, or cooperation among components. model is incapable of adequately describing network-based software architectures, since Perry and Wolf [105] describe connecting elements vaguely as the glue that holds the the nature, location, and movement of data elements within the system is often the single various pieces of the architecture together. A more precise definition is provided by Shaw most significant determinant of system behavior. and Clements [122]: A connector is an abstract mechanism that mediates communication,

1.2.1 Components coordination, or cooperation among components. Examples include shared

representations, remote procedure calls, message-passing protocols, and data streams. A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface. Perhaps the best way to think about connectors is to contrast them with components.

Components are the most easily recognized aspect of software architecture. Perry and Connectors enable communication between components by transferring data elements

Wolf’s [105] processing elements are defined as those components that supply the from one interface to another without changing the data. Internally, a connector may transformation on the data elements. Garlan and Shaw [53] describe components simply consist of a subsystem of components that transform the data for transfer, perform the as the elements that perform computation. Our definition attempts to be more precise in transfer, and then reverse the transformation for delivery. However, the external making the distinction between components and the software within connectors. behavioral abstraction captured by the architecture ignores those details. In contrast, a

A component is an abstract unit of software instructions and internal state that component may, but not always will, transform data from the external perspective. provides a transformation of data via its interface. Example transformations include

9 10 1.2.3 Data 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. A datum is an element of information that is transferred from a component, or received by a component, via a connector. 1.3 Configurations 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 A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time. much of the research labelled software architecture [1, 5, 9, 53, 56, 117-122, 128]. Abowd et al. [1] define architectural description as supporting the description of systems Boasson [24] criticizes current software architecture research for its emphasis on in terms of three basic syntactic classes: components, which are the locus of computation; component structures and architecture development tools, suggesting that more focus connectors, which define the interactions between components; and configurations, which should be placed on data-centric architectural modeling. Similar comments are made by are collections of interacting components and connectors. Various style-specific concrete Jackson [67]. notations may be used to represent these visually, facilitate the description of legal A datum is an element of information that is transferred from a component, or received computations and interactions, and constrain the set of desirable systems. by a component, via a connector. Examples include byte-sequences, messages, marshalled Strictly speaking, one might think of a configuration as being equivalent to a set of parameters, and serialized objects, but do not include information that is permanently specific constraints on component interaction. For example, Perry and Wolf [105] include resident or hidden within a component. From the architectural perspective, a “file” is a topology in their definition of architectural form relationships. However, separating the transformation that a file system component might make from a “file name” datum active topology from more general constraints allows an architect to more easily received on its interface to a sequence of bytes recorded within an internally hidden distinguish the active configuration from the potential domain of all legitimate storage system. Components can also generate data, as in the case of a software configurations. Additional rationale for distinguishing configurations within architectural encapsulation of a clock or sensor. description languages is presented in Medvidovic and Taylor [86]. 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 1.4 Properties particularly evident in the comparison of mobile code design paradigms [50], where the The set of architectural properties of a software architecture includes all properties that choice must be made between interacting with a component directly or transforming the derive from the selection and arrangement of components, connectors, and data within the component into a data element, transferring it across a network, and then transforming it system. Examples include both the functional properties achieved by the system and non-

11 12 functional properties, such as relative ease of evolution, reusability of components, same type of system set in different environments. Styles are a mechanism for efficiency, and dynamic extensibility, often referred to as quality attributes [9]. categorizing architectures and for defining their common characteristics [38]. Each style

Properties are induced by the set of constraints within an architecture. Constraints are provides an abstraction for the interactions of components, capturing the essence of a often motivated by the application of a software engineering principle [58] to an aspect of pattern of interaction by ignoring the incidental details of the rest of the architecture [117]. the architectural elements. For example, the uniform pipe-and-filter style obtains the Perry and Wolf [105] define architectural style as an abstraction of element types and qualities of reusability of components and configurability of the application by applying formal aspects from various specific architectures, perhaps concentrating on only certain generality to its component interfaces — constraining the components to a single interface aspects of an architecture. An architectural style encapsulates important decisions about type. Hence, the architectural constraint is “uniform component interface,” motivated by the architectural elements and emphasizes important constraints on the elements and their the generality principle, in order to obtain two desirable qualities that will become the relationships. This definition allows for styles that focus only on the connectors of an architectural properties of reusable and configurable components when that style is architecture, or on specific aspects of the component interfaces. instantiated within an architecture. In contrast, Garlan and Shaw [53], Garlan et al. [56], and Shaw and Clements [122] all

The goal of architectural design is to create an architecture with a set of architectural define style in terms of a pattern of interactions among typed components. Specifically, an properties that form a superset of the system requirements. The relative importance of the architectural style determines the vocabulary of components and connectors that can be various architectural properties depends on the nature of the intended system. Section 2.3 used in instances of that style, together with a set of constraints on how they can be examines the properties that are of particular interest to network-based application combined [53]. This restricted view of architectural styles is a direct result of their architectures. 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 1.5 Styles box and line diagrams. Abowd et al. [1] go further and define this explicitly as viewing the

An architectural style is a coordinated set of architectural constraints collection of conventions that are used to interpret a class of architectural descriptions as that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that defining an architectural style. conforms to that style. New architectures can be defined as instances of specific styles [38]. Since Since an architecture embodies both functional and non-functional properties, it can be architectural styles may address different aspects of software architecture, a given difficult to directly compare architectures for different types of systems, or for even the

13 14 architecture may be composed of multiple styles. Likewise, a hybrid style can be formed 1.6 Patterns and Pattern Languages by combining multiple basic styles into a single coordinated style. In parallel with the software engineering research in architectural styles, the object-

Some architectural styles are often portrayed as “silver bullet” solutions for all forms oriented programming community has been exploring the use of design patterns and of software. However, a good designer should select a style that matches the needs of the pattern languages to describe recurring abstractions in object-based software particular problem being solved [119]. Choosing the right architectural style for a development. A design pattern is defined as an important and recurring system construct. network-based application requires an understanding of the problem domain [67] and A pattern language is a system of patterns organized in a structure that guides the patterns’ thereby the communication needs of the application, an awareness of the variety of application [70]. Both concepts are based on the writings of Alexander et al. [3, 4] with architectural styles and the particular concerns they address, and the ability to anticipate regard to building architecture. the sensitivity of each interaction style to the characteristics of network-based The design space of patterns includes implementation concerns specific to the communication [133]. techniques of object-oriented programming, such as class inheritance and interface

Unfortunately, using the term style to refer to a coordinated set of constraints often composition, as well as the higher-level design issues addressed by architectural styles leads to confusion. This usage differs substantially from the etymology of style, which [51]. In some cases, architectural style descriptions have been recast as architectural would emphasize personalization of the design process. Loerke [76] devotes a chapter to patterns [120]. However, a primary benefit of patterns is that they can describe relatively denigrating the notion that personal stylistic concerns have any place in the work of a complex protocols of interactions between objects as a single abstraction [91], thus professional architect. Instead, he describes styles as the critics’ view of past architecture, including both constraints on behavior and specifics of the implementation. In general, a where the available choice of materials, the community culture, or the ego of the local pattern, or pattern language in the case of multiple integrated patterns, can be thought of as ruler were responsible for the architectural style, not the designer. In other words, Loerke a recipe for implementing a desired set of interactions among objects. In other words, a views the real source of style in traditional building architecture to be the set of constraints pattern defines a process for solving a problem by following a path of design and applied to the design, and attaining or copying a specific style should be the least of the implementation choices [34]. designer’s goals. Since referring to a named set of constraints as a style makes it easier to Like software architectural styles, the software patterns research has deviated communicate the characteristics of common constraints, we use architectural styles as a somewhat from its origin in building architecture. Indeed, Alexander’s notion of patterns method of abstraction, rather than as an indicator of personalized design. centers not on recurring arrangements of architectural elements, but rather on the recurring

pattern of events—human activity and emotion—that take place within a space, with the

15 16 understanding that a pattern of events cannot be separated from the space where it occurs In addition to the many architectures within a system, and the many architectural styles

[3]. Alexander’s design philosophy is to identify patterns of life that are common to the from which the architectures are composed, it is also possible to view an architecture from target culture and determine what architectural constraints are needed to differentiate a many different perspectives. Perry and Wolf [105] describe three important views in given space such that it enables the desired patterns to occur naturally. Such patterns exist software architecture: processing, data, and connection views. A process view emphasizes at multiple levels of abstraction and at all scales. the data flow through the components and some aspects of the connections among the

As an element in the world, each pattern is a relationship between a certain components with respect to the data. A data view emphasizes the processing flow, with context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves. less emphasis on the connectors. A connection view emphasizes the relationship between As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the components and the state of communication. given system of forces, wherever the context makes it relevant. The pattern is, in short, at the same time a thing, which happens in the Multiple architectural views are common within case studies of specific architectures world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is [9]. One architectural design methodology, the 4+1 View Model [74], organizes the alive, and a description of the process which will generate that thing. [3] description of a software architecture using five concurrent views, each of which In many ways, Alexander’s patterns have more in common with software architectural addresses a specific set of concerns. styles than the design patterns of OOPL research. An architectural style, as a coordinated set of constraints, is applied to a design space in order to induce the architectural 1.8 Related Work properties that are desired of the system. By applying a style, an architect is differentiating I include here only those areas of research that define software architecture or describe the software design space in the hope that the result will better match the forces inherent in software architectural styles. Other areas for software architecture research include the application, thus leading to system behavior that enhances the natural pattern rather architectural analysis techniques, architecture recovery and re-engineering, tools and than conflicting with it. environments for architectural design, architecture refinement from specification to

implementation, and case studies of deployed software architectures [55]. Related work in 1.7 Views the areas of style classification, distributed process paradigms, and middleware are An architectural viewpoint is often application-specific and varies widely based on the application domain. ... we have seen architectural viewpoints that discussed in Chapter 3. address a variety of issues, including: temporal issues, state and control approaches, data representation, transaction life cycle, security safeguards, and peak demand and graceful degradation. No doubt there are many more possible viewpoints. [70]

17 18 1.8.1 Design Methodologies described in [53], including information on the kinds of problems best suited to each

Most early research on software architecture was concentrated on design methodologies. architecture. Buschmann et al. [28] provide a comprehensive examination of the

For example, object-oriented design [25] advocates a way to structure problems that leads architectural patterns common to object-based development. Both references are purely naturally to an object-based architecture (or, more accurately, does not lead naturally to descriptive and make no attempt to compare or illustrate the differences among any other form of architecture). One of the first design methodologies to emphasize design architectural patterns. at the architectural level is Jackson System Development [30]. JSD intentionally Tepfenhart and Cusick [129] use a two dimensional map to differentiate among structures the analysis of a problem so that it leads to a style of architecture that combines domain taxonomies, domain models, architectural styles, frameworks, kits, design pipe-and-filter (data flow) and process control constraints. These design methodologies patterns, and applications. In the topology, design patterns are predefined design tend to produce only one style of architecture. structures used as building blocks for a software architecture, whereas architectural styles

There has been some initial work investigating methodologies for the analysis and are sets of operational characteristics that identify an architectural family independent of development of architectures. Kazman et al. have described design methods for eliciting application domain. However, they fail to define architecture itself. the architectural aspects of a design through scenario-based analysis with SAAM [68] and 1.8.3 Reference Models and Domain-specific Software Architectures (DSSA) architectural trade-off analysis via ATAM [69]. Shaw [119] compares a variety of box- Reference models are developed to provide conceptual frameworks for describing and-arrow designs for an automobile cruise control system, each done using a different architectures and showing how components are related to each other [117]. The Object design methodology and encompassing several architectural styles. Management Architecture (OMA), developed by the OMG [96] as a reference model for

1.8.2 Handbooks for Design, Design Patterns, and Pattern Languages brokered distributed object architectures, specifies how objects are defined and created,

Shaw [117] advocates the development of architectural handbooks along the same lines as how client applications invoke objects, and how objects can be shared and reused. The traditional engineering disciplines. The object-oriented programming community has emphasis is on management of distributed objects, rather than efficient application taken the lead in producing catalogs of design patterns, as exemplified by the “Gang of interaction.

Four” book [51] and the essays edited by Coplien and Schmidt [33]. Hayes-Roth et al. [62] define domain-specific software architecture (DSSA) as

Software design patterns tend to be more problem-oriented than architectural styles. comprising: a) a reference architecture, which describes a general computational

Shaw [120] presents eight example architectural patterns based on the architectural styles framework for a significant domain of applications, b) a component library, which

19 20 contains reusable chunks of domain expertise, and c) an application configuration method for specifying the interactions between architectural components by specifying connector for selecting and configuring components within the architecture to meet particular types by their interaction protocols. application requirements. Tracz [130] provides a general overview of DSSA. Like design methodologies, ADLs often introduce specific architectural assumptions

DSSA projects have been successful at transferring architectural decisions to running that may impact their ability to describe some architectural styles, and may conflict with systems by restricting the software development space to a specific architectural style that the assumptions in existing middleware [38]. In some cases, an ADL is designed matches the domain requirements [88]. Examples include ADAGE [10] for avionics, AIS specifically for a single architectural style, thus improving its capacity for specialized

[62] for adaptive intelligent systems, and MetaH [132] for missile guidance, navigation, description and analysis at the cost of generality. For example, C2SADEL [88] is an ADL and control systems. DSSA emphasize reuse of components within a common designed specifically to describe architectures developed in the C2 style [128]. In contrast, architectural domain, rather than selecting an architectural style that is specific to each ACME [57] is an ADL that attempts to be as generic as possible, but with the trade-off system. being that it doesn’t support style-specific analysis and the building of actual applications;

rather, its focus is on the interchange among analysis tools. 1.8.4 Architecture Description Languages (ADL)

Most of the recent published work regarding software architectures is in the area of 1.8.5 Formal Architectural Models architecture description languages (ADL). An ADL is, according to Medvidovic and Abowd et al. [1] claim that architectural styles can be described formally in terms of a

Taylor [86], a language that provides features for the explicit specification and modeling small set of mappings from the syntactic domain of architectural descriptions (box-and- of a software system’s conceptual architecture, including at a minimum: components, line diagrams) to the semantic domain of architectural meaning. However, this assumes component interfaces, connectors, and architectural configurations. that the architecture is the description, rather than an abstraction of a running system.

Darwin is a declarative language which is intended to be a general purpose notation Inverardi and Wolf [65] use the Chemical Abstract Machine (CHAM) formalism to for specifying the structure of systems composed of diverse components using diverse model software architecture elements as chemicals whose reactions are controlled by interaction mechanisms [81]. Darwin’s interesting qualities are that it allows the explicitly stated rules. It specifies the behavior of components according to how they specification of distributed architectures and dynamically composed architectures [82]. transform available data elements and uses composition rules to propagate the individual

UniCon [118] is a language and associated toolset for composing an architecture from transformations into an overall system result. While this is an interesting model, it is a restricted set of component and connector examples. Wright [5] provides a formal basis

21 22 unclear as to how CHAM could be used to describe any form of architecture whose CHAPTER 2 purpose goes beyond transforming a data stream. Network-based Application Architectures Rapide [78] is a concurrent, event-based simulation language specifically designed for defining and simulating system architectures. The simulator produces a partially-ordered This chapter continues our discussion of background material by focusing on network- set of events that can be analyzed for conformance to the architectural constraints on based application architectures and describing how styles can be used to guide their interconnection. Le Métayer [75] presents a formalism for the definition of architectures architectural design. in terms of graphs and graph grammars. 2.1 Scope 1.9 Summary Architecture is found at multiple levels within software systems. This dissertation This chapter examined the background for this dissertation. Introducing and formalizing a examines the highest level of abstraction in software architecture, where the interactions consistent set of terminology for software architecture concepts is necessary to avoid the among components are capable of being realized in network communication. We limit our confusion between architecture and architecture description that is common in the discussion to styles for network-based application architectures in order to reduce the literature, particularly since much of the prior research on architecture excludes data as an dimensions of variance among the styles studied. important architectural element. I concluded with a survey of other research related to 2.1.1 Network-based vs. Distributed software architecture and architectural styles.

The next two chapters continue our discussion of background material by focusing on The primary distinction between network-based architectures and software architectures network-based application architectures and describing how styles can be used to guide in general is that communication between components is restricted to message passing [6], their architectural design, followed by a survey of common architectural styles using a or the equivalent of message passing if a more efficient mechanism can be selected at run- classification methodology that highlights the architectural properties induced when the time based on the location of components [128]. styles are applied to an architecture for network-based hypermedia. 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

23 24 necessarily in a fashion that is transparent to the user. In some cases it is desirable for the 2.2 Evaluating the Design of Application Architectures user to be aware of the difference between an action that requires a network request and One of the goals of this dissertation is to provide design guidance for the task of selecting one that is satisfiable on their local system, particularly when network usage implies an or creating the most appropriate architecture for a given application domain, keeping in extra transaction cost [133]. This dissertation covers network-based systems by not mind that an architecture is the realization of an architectural design and not the design limiting the candidate styles to those that preserve transparency for the user. itself. An architecture can be evaluated by its run-time characteristics, but we would

obviously prefer an evaluation mechanism that could be applied to the candidate 2.1.2 Application Software vs. Networking Software architectural designs before having to implement all of them. Unfortunately, architectural Another restriction on the scope of this dissertation is that we limit our discussion to designs are notoriously hard to evaluate and compare in an objective manner. Like most application architectures, excluding the operating system, networking software, and some artifacts of creative design, architectures are normally presented as a completed work, as if architectural styles that would only use a network for system support (e.g., process control the design simply sprung fully-formed from the architect’s mind. In order to evaluate an styles [53]). Applications represent the “business-aware” functionality of a system [131]. architectural design, we need to examine the design rationale behind the constraints it Application software architecture is an abstraction level of an overall system, in which places on a system, and compare the properties derived from those constraints to the target the goals of a user action are representable as functional architectural properties. For application’s objectives. example, a hypermedia application must be concerned with the location of information The first level of evaluation is set by the application’s functional requirements. For pages, performing requests, and rendering data streams. This is in contrast to a networking example, it makes no sense to evaluate the design of a process control architecture against abstraction, where the goal is to move bits from one location to another without regard to the requirements of a distributed hypermedia system, since the comparison is moot if the why those bits are being moved. It is only at the application level that we can evaluate architecture would not function. Although this will eliminate some candidates, in most design trade-offs based on the number of interactions per user action, the location of cases there will remain many other architectural designs that are capable of meeting the application state, the effective throughput of all data streams (as opposed to the potential application’s functional needs. The remainder differ by their relative emphasis on the non- throughput of a single data stream), the extent of communication being performed per user functional requirements—the degree to which each architecture would support the various action, etc. non-functional architectural properties that have been identified as necessary for the

system. Since properties are created by the application of architectural constraints, it is

possible to evaluate and compare different architectural designs by identifying the

25 26 constraints within each architecture, evaluating the set of properties induced by each The evaluation of architectural properties within a tree of styles is specific to the needs constraint, and comparing the cumulative properties of the design to those properties of a particular application domain because the impact of a given constraint is often required of the application. dependent on the application characteristics. For example, the pipe-and-filter style enables

As described in the previous chapter, an architectural style is a coordinated set of several positive architectural properties when used within a system that requires data architectural constraints that has been given a name for ease of reference. Each transformations between components, whereas it would add nothing but overhead to a architectural design decision can be seen as an application of a style. Since the addition of system that consists only of control messages. Since it is rarely useful to compare a constraint may derive a new style, we can think of the space of all possible architectural architectural designs across different application domains, the simplest means of ensuring styles as a derivation tree, with its root being the null style (empty set of constraints). consistency is to make the tree domain-specific.

When their constraints do not conflict, styles can be combined to form hybrid styles, Design evaluation is frequently a question of choosing between trade-offs. Perry and eventually culminating in a hybrid style that represents a complete abstraction of the Wolf [105] describe a method of recognizing trade-offs explicitly by placing a numeric architectural design. An architectural design can therefore be analyzed by breaking-down weight against each property to indicate its relative importance to the architecture, thus its set of constraints into a derivation tree and evaluating the cumulative effect of the providing a normalized metric for comparing candidate designs. However, in order to be a constraints represented by that tree. If we understand the properties induced by each basic meaningful metric, each weight would have to be carefully chosen using an objective style, then traversing the derivation tree gives us an understanding of the overall design’s scale that is consistent across all properties. In practice, no such scale exists. Rather than architectural properties. The specific needs of an application can then be matched against having the architect fiddle with weight values until the result matches their intuition, I the properties of the design. Comparison becomes a relatively simple matter of identifying prefer to present all of the information to the architect in a readily viewable form, and let which architectural design satisfies the most desired properties for that application. the architect’s intuition be guided by the visual pattern. This will be demonstrated in the

Care must be taken to recognize when the effects of one constraint may counteract the next chapter. benefits of some other constraint. Nevertheless, it is possible for an experienced software 2.3 Architectural Properties of Key Interest architect to build such a derivation tree of architectural constraints for a given application This section describes the architectural properties used to differentiate and classify domain, and then use the tree to evaluate many different architectural designs for architectural styles in this dissertation. It is not intended to be a comprehensive list. I have applications within that domain. Thus, building a derivation tree provides a mechanism included only those properties that are clearly influenced by the restricted set of styles for architectural design guidance.

27 28 surveyed. Additional properties, sometimes referred to as software qualities, are covered communication overhead, is transferred between components. Overhead can be separated by most textbooks on software engineering (e.g., [58]). Bass et al. [9] examine qualities in into initial setup overhead and per-interaction overhead, a distinction which is useful for regards to software architecture. identifying connectors that can share setup overhead across multiple interactions

(amortization). Bandwidth is a measure of the maximum available throughput over a 2.3.1 Performance given network link. Usable bandwidth refers to that portion of bandwidth which is One of the main reasons to focus on styles for network-based applications is because actually available to the application. component interactions can be the dominant factor in determining user-perceived Styles impact network performance by their influence on the number of interactions performance and network efficiency. Since the architectural style influences the nature of per user action and the granularity of data elements. A style that encourages small, those interactions, selection of an appropriate architectural style can make the difference strongly typed interactions will be efficient in an application involving small data transfers between success and failure in the deployment of a network-based application. among known components, but will cause excessive overhead within applications that The performance of a network-based application is bound first by the application involve large data transfers or negotiated interfaces. Likewise, a style that involves the requirements, then by the chosen interaction style, followed by the realized architecture, coordination of multiple components arranged to filter a large data stream will be out of and finally by the implementation of each component. In other words, software cannot place in an application that primarily requires small control messages. avoid the basic cost of achieving the application needs; e.g., if the application requires that 2.3.1.2 User-perceived Performance data be located on system A and processed on system B, then the software cannot avoid User-perceived performance differs from network performance in that the performance of moving that data from A to B. Likewise, an architecture cannot be any more efficient than an action is measured in terms of its impact on the user in front of an application rather its interaction style allows; e.g., the cost of multiple interactions to move the data from A than the rate at which the network moves information. The primary measures for user- to B cannot be any less than that of a single interaction from A to B. Finally, regardless of perceived performance are latency and completion time. the quality of an architecture, no interaction can take place faster than a component Latency is the time period between initial stimulus and the first indication of a implementation can produce data and its recipient can consume data. response. Latency occurs at several points in the processing of a network-based 2.3.1.1 Network Performance application action: 1) the time needed for the application to recognize the event that Network performance measures are used to describe some attributes of communication. initiated the action; 2) the time required to setup the interactions between components; 3) Throughput is the rate at which information, including both application data and the time required to transmit each interaction to the components; 4) the time required to

29 30 process each interaction on those components; and, 5) the time required to complete 2.3.1.3 Network Efficiency sufficient transfer and processing of the result of the interactions before the application is An interesting observation about network-based applications is that the best application able to begin rendering a usable result. It is important to note that, although only (3) and performance is obtained by not using the network. This essentially means that the most

(5) represent actual network communication, all five points can be impacted by the efficient architectural styles for a network-based application are those that can effectively architectural style. Furthermore, multiple component interactions per user action are minimize use of the network when it is possible to do so, through reuse of prior additive to latency unless they take place in parallel. interactions (caching), reduction of the frequency of network interactions in relation to

Completion is the amount of time taken to complete an application action. Completion user actions (replicated data and disconnected operation), or by removing the need for time is dependent upon all of the aforementioned measures. The difference between an some interactions by moving the processing of data closer to the source of the data action’s completion time and its latency represents the degree to which the application is (mobile code). incrementally processing the data being received. For example, a Web browser that can The impact of the various performance issues is often related to the scope of render a large image while it is being received provides significantly better user-perceived distribution for the application. The benefits of a style under local conditions may become performance than one that waits until the entire image is completely received prior to drawbacks when faced with global conditions. Thus, the properties of a style must be rendering, even though both experience the same network performance. framed in relation to the interaction distance: within a single process, across processes on

It is important to note that design considerations for optimizing latency will often have a single host, inside a local-area network (LAN), or spread across a wide-area network the side-effect of degrading completion time, and vice versa. For example, compression of (WAN). Additional concerns become evident when interactions across a WAN, where a a data stream can produce a more efficient encoding if the algorithm samples a significant single organization is involved, are compared to interactions across the Internet, involving portion of the data before producing the encoded transformation, resulting in a shorter multiple trust boundaries. completion time to transfer the encoded data across the network. However, if this 2.3.2 Scalability compression is being performed on-the-fly in response to a user action, then buffering a Scalability refers to the ability of the architecture to support large numbers of components, large sample before transfer may produce an unacceptable latency. Balancing these trade- or interactions among components, within an active configuration. Scalability can be offs can be difficult, particularly when it is unknown whether the recipient cares more improved by simplifying components, by distributing services across many components about latency (e.g., Web browsers) or completion (e.g., Web spiders). (decentralizing the interactions), and by controlling interactions and configurations as a

31 32 result of monitoring. Styles influence these factors by determining the location of of network-based systems is dynamic modifiability [98], where the modification is made application state, the extent of distribution, and the coupling between components. to a deployed application without stopping and restarting the entire system.

Scalability is also impacted by the frequency of interactions, whether the load on a Even if it were possible to build a software system that perfectly matches the component is distributed evenly over time or occurs in peaks, whether an interaction requirements of its users, those requirements will change over time just as society changes requires guaranteed delivery or a best-effort, whether a request involves synchronous or over time. Because the components participating in a network-based application may be asynchronous handling, and whether the environment is controlled or anarchic (i.e., can distributed across multiple organizational boundaries, the system must be prepared for you trust the other components?). gradual and fragmented change, where old and new implementations coexist, without

preventing the new implementations from making use of their extended capabilities. 2.3.3 Simplicity 2.3.4.1 Evolvability The primary means by which architectural styles induce simplicity is by applying the Evolvability represents the degree to which a component implementation can be changed principle of separation of concerns to the allocation of functionality within components. If without negatively impacting other components. Static evolution of components generally functionality can be allocated such that the individual components are substantially less depends on how well the architectural abstraction is enforced by the implementation, and complex, then they will be easier to understand and implement. Likewise, such separation thus is not something unique to any particular architectural style. Dynamic evolution, eases the task of reasoning about the overall architecture. I have chosen to lump the however, can be influenced by the style if it includes constraints on the maintenance and qualities of complexity, understandability, and verifiability under the general property of location of application state. The same techniques used to recover from partial failure simplicity, since they go hand-in-hand for a network-based system. conditions in a distributed system [133] can be used to support dynamic evolution. Applying the principle of generality to architectural elements also improves 2.3.4.2 Extensibility simplicity, since it decreases variation within an architecture. Generality of connectors Extensibility is defined as the ability to add functionality to a system [108]. Dynamic leads to middleware [22]. extensibility implies that functionality can be added to a deployed system without

2.3.4 Modifiability impacting the rest of the system. Extensibility is induced within an architectural style by

Modifiability is about the ease with which a change can be made to an application reducing the coupling between components, as exemplified by event-based integration. architecture. Modifiability can be further broken down into evolvability, extensibility, customizability, configurability, and reusability, as described below. A particular concern

33 34 2.3.4.3 Customizability 2.3.5 Visibility

Customizability refers to the ability to temporarily specialize the behavior of an Styles can also influence the visibility of interactions within a network-based application architectural element, such that it can then perform an unusual service. A component is by restricting interfaces via generality or providing access to monitoring. Visibility in this customizable if it can be extended by one client of that component’s services without case refers to the ability of a component to monitor or mediate the interaction between two adversely impacting other clients of that component [50]. Styles that support other components. Visibility can enable improved performance via shared caching of customization may also improve simplicity and scalability, since service components can interactions, scalability through layered services, reliability through reflective monitoring, be reduced in size and complexity by directly implementing only the most frequent and security by allowing the interactions to be inspected by mediators (e.g., network services and allowing infrequent services to be defined by the client. Customizability is a firewalls). The mobile agent style is an example where the lack of visibility may lead to property induced by the remote evaluation and code-on-demand styles. security concerns.

2.3.4.4 Configurability This usage of the term visibility differs from that in Ghezzi et al. [58], where they are

Configurability is related to both extensibility and reusability in that it refers to post- referring to visibility into the development process rather than the product. deployment modification of components, or configurations of components, such that they 2.3.6 Portability are capable of using a new service or data element type. The pipe-and-filter and code-on- Software is portable if it can run in different environments [58]. Styles that induce demand styles are two examples that induce configurability of configurations and portability include those that move code along with the data to be processed, such as the components, respectively. virtual machine and mobile agent styles, and those that constrain the data elements to a set 2.3.4.5 Reusability of standardized formats. 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 2.3.7 Reliability mechanisms for inducing reusability within architectural styles is reduction of coupling Reliability, within the perspective of application architectures, can be viewed as the

(knowledge of identity) between components and constraining the generality of degree to which an architecture is susceptible to failure at the system level in the presence component interfaces. The uniform pipe-and-filter style exemplifies these types of of partial failures within components, connectors, or data. Styles can improve reliability constraints. by avoiding single points of failure, enabling redundancy, allowing monitoring, or

reducing the scope of failure to a recoverable action.

35 36 2.4 Summary CHAPTER 3

This chapter examined the scope of the dissertation by focusing on network-based Network-based Architectural Styles 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 This chapter presents a survey of common architectural styles for network-based rest of the dissertation for the comparison and evaluation of architectural styles. application software within a classification framework that evaluates each style according

The next chapter presents a survey of common architectural styles for network-based to the architectural properties it would induce if applied to an architecture for a application software within a classification framework that evaluates each style according prototypical network-based hypermedia system. 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.

37 38 I have intentionally excluded styles that do not enhance the communication or Focusing on a particular type of software allows us to identify the advantages of one style interaction properties when combined with one of the surveyed styles to form a network- over another in the same way that a designer of a system would evaluate those advantages. based application. For example, the blackboard architectural style [95] consists of a Since we do not intend to declare any single style as being universally desirable for all central repository and a set of components (knowledge sources) that operate types of software, restricting the focus of our evaluation simply reduces the dimensions opportunistically upon the repository. A blackboard architecture can be extended to a over which we need to evaluate. Evaluating the same styles for other types of application network-based system by distributing the components, but the properties of such an software is an open area for future research. extension are entirely based on the interaction style chosen to support the distribution — 3.1.3 Visualization notifications via event-based integration, polling a la client-server, or replication of the I use a table of style versus architectural properties as the primary visualization for this repository. Thus, there would be no added value from including it in the classification, classification. The table values indicate the relative influence that the style for a given row even though the hybrid style is network-capable. has on a column’s property. Minus (−) symbols accumulate for negative influences and

3.1.2 Style-induced Architectural Properties plus (+) symbols for positive, with plus-minus (±) indicating that it depends on some

My classification uses relative changes in the architectural properties induced by each aspect of the problem domain. Although this is a gross simplification of the details style as a means of illustrating the effect of each architectural style when applied to a presented in each section, it does indicate the degree to which a style has addressed (or system for distributed hypermedia. Note that the evaluation of a style for a given property ignored) an architectural property. depends on the type of system interaction being studied, as described in Section 2.2. The An alternative visualization would be a property-based derivation graph for architectural properties are relative in the sense that adding an architectural constraint may classifying architectural styles. The styles would be classified according to how they are improve or reduce a given property, or simultaneously improve one aspect of the property derived from other styles, with the arcs between styles illustrated by architectural and reduce some other aspect of the property. Likewise, improving one property may lead properties gained or lost. The starting point of the graph would be the null style (no to the reduction of another. constraints). It is possible to derive such a graph directly from the descriptions.

Although our discussion of architectural styles will include those applicable to a wide range of network-based systems, our evaluation of each style will be based on its impact upon an architecture for a single type of software: network-based hypermedia systems.

39 40 3.2 Data-flow Styles (extensibility) and old filters can be replaced by improved ones (evolvability). Fourth,

they permit certain kinds of specialized analysis (verifiability), such as throughput and

deadlock analysis. Finally, they naturally support concurrent execution (user-perceived Style Derivation Net Perform. UP Perform. Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability PF ± +++ ++ performance). UPF PF − ± ++ + + ++ ++ + Disadvantages of the PF style include: propagation delay is added through long Table 3-1. Evaluation of Data-flow Styles for Network-based Hypermedia pipelines, batch sequential processing occurs if a filter cannot incrementally process its 3.2.1 Pipe and Filter (PF) inputs, and no interactivity is allowed. A filter cannot interact with its environment In a pipe and filter style, each component (filter) reads streams of data on its inputs and because it cannot know that any particular output stream shares a controller with any produces streams of data on its outputs, usually while applying a transformation to the particular input stream. These properties decrease user-perceived performance if the input streams and processing them incrementally so that output begins before the input is problem being addressed does not fit the pattern of a data flow stream. completely consumed [53]. This style is also referred to as a one-way data flow network One aspect of PF styles that is rarely mentioned is that there is an implied “invisible [6]. The constraint is that a filter must be completely independent of other filters (zero hand” that arranges the configuration of filters in order to establish the overall application. coupling): it must not share state, control thread, or identity with the other filters on its A network of filters is typically arranged just prior to each activation, allowing the upstream and downstream interfaces [53]. application to specify the configuration of filter components based on the task at hand and Abowd et al. [1] provide an extensive formal description of the pipe and filter style the nature of the data streams (configurability). This controller function is considered a using the Z language. The Khoros software development environment for image separate operational phase of the system, and hence a separate architecture, even though processing [112] provides a good example of using the pipe and filter style to build a one cannot exist without the other. range of applications.

Garlan and Shaw [53] describe the advantageous properties of the pipe and filter style 3.2.2 Uniform Pipe and Filter (UPF) as follows. First, PF allows the designer to understand the overall input/output of the The uniform pipe and filter style adds the constraint that all filters must have the same system as a simple composition of the behaviors of the individual filters (simplicity). interface. The primary example of this style is found in the Unix operating system, where

Second, PF supports reuse: any two filters can be hooked together, provided they agree on filter processes have an interface consisting of one input data stream of characters (stdin) the data that is being transmitted between them (reusability). Third, PF systems can be and two output data streams of characters (stdout and stderr). Restricting the interface easily maintained and enhanced: new filters can be added to existing systems

41 42 allows independently developed filters to be arranged at will to form new applications. It 3.3.2 Cache ($) also simplifies the task of understanding how a given filter works. A variant of replicated repository is found in the cache style: replication of the result of an

A disadvantage of the uniform interface is that it may reduce network performance if individual request such that it may be reused by later requests. This form of replication is the data needs to be converted to or from its natural format. most often found in cases where the potential data set far exceeds the capacity of any one

client, as in the WWW [20], or where complete access to the repository is unnecessary. 3.3 Replication Styles Lazy replication occurs when data is replicated upon a not-yet-cached response for a

request, relying on locality of reference and commonality of interest to propagate useful

Style Derivation items into the cache for later reuse. Active replication can be performed by pre-fetching NetPerform. UP Perform. Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability RR ++ + + cacheable entries based on anticipated requests. $RR ++++

Table 3-2. Evaluation of Replication Styles for Network-based Hypermedia Caching provides slightly less improvement than the replicated repository style in

3.3.1 Replicated Repository (RR) terms of user-perceived performance, since more requests will miss the cache and only

Systems based on the replicated repository style [6] improve the accessibility of data and recently accessed data will be available for disconnected operation. On the other hand, scalability of services by having more than one process provide the same service. These caching is much easier to implement, doesn’t require as much processing and storage, and decentralized servers interact to provide clients the illusion that there is just one, is more efficient because data is transmitted only when it is requested. The cache style centralized service. Distributed filesystems, such as XMS [49], and remote versioning becomes network-based when it is combined with a client-stateless-server style. 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.

43 44 3.4 Hierarchical Styles Separation of concerns is the principle behind the client-server constraints. A proper

separation of functionality should simplify the server component in order to improve

scalability. This simplification usually takes the form of moving all of the user interface Style Derivation Net Perform. UP Perform. Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability CS +++ functionality into the client component. The separation also allows the two types of LS −++ ++ components to evolve independently, provided that the interface doesn’t change. LCS CS+LS −+++++ + + CSS CS −++++ ++ The basic form of client-server does not constrain how application state is partitioned C$SS CSS+$ −++++++ + + LC$SS LCS+C$SS −±++++++++ ++++ between client and server components. It is often referred to by the mechanisms used for RS CS +−++ − RDA CS +−− + − the connector implementation, such as remote procedure call [23] or message-oriented Table 3-3. Evaluation of Hierarchical Styles for Network-based Hypermedia middleware [131]. 3.4.1 Client-Server (CS) 3.4.2 Layered System (LS) and Layered-Client-Server (LCS) The client-server style is the most frequently encountered of the architectural styles for A layered system is organized hierarchically, each layer providing services to the layer network-based applications. A server component, offering a set of services, listens for above it and using services of the layer below it [53]. Although layered system is requests upon those services. A client component, desiring that a service be performed, considered a “pure” style, its use within network-based systems is limited to its sends a request to the server via a connector. The server either rejects or performs the combination with the client-server style to provide layered-client-server. request and sends a response back to the client. A variety of client-server systems are Layered systems reduce coupling across multiple layers by hiding the inner layers surveyed by Sinha [123] and Umar [131]. from all except the adjacent outer layer, thus improving evolvability and reusability. Andrews [6] describes client-server components as follows: A client is a triggering Examples include the processing of layered communication protocols, such as the TCP/IP process; a server is a reactive process. Clients make requests that trigger reactions from and OSI protocol stacks [138], and hardware interface libraries. The primary disadvantage servers. Thus, a client initiates activity at times of its choosing; it often then delays until its of layered systems is that they add overhead and latency to the processing of data, request has been serviced. On the other hand, a server waits for requests to be made and reducing user-perceived performance [32]. then reacts to them. A server is usually a non-terminating process and often provides Layered-client-server adds proxy and gateway components to the client-server style. A service to more than one client. proxy [116] acts as a shared server for one or more client components, taking requests and

45 46 forwarding them, with possible translation, to server components. A gateway component because not having to store state between requests allows the server component to quickly appears to be a normal server to clients or proxies that request its services, but is in fact free resources and further simplifies implementation. forwarding those requests, with possible translation, to its “inner-layer” servers. These The disadvantage of client-stateless-server is that it may decrease network additional mediator components can be added in multiple layers to add features like load performance by increasing the repetitive data (per-interaction overhead) sent in a series of balancing and security checking to the system. requests, since that data cannot be left on the server in a shared context.

Architectures based on layered-client-server are referred to as two-tiered, three-tiered, 3.4.4 Client-Cache-Stateless-Server (C$SS) or multi-tiered architectures in the information systems literature [131]. The client-cache-stateless-server style derives from the client-stateless-server and cache LCS is also a solution to managing identity in a large scale distributed system, where styles via the addition of cache components. A cache acts as a mediator between client and complete knowledge of all servers would be prohibitively expensive. Instead, servers are server in which the responses to prior requests can, if they are considered cacheable, be organized in layers such that rarely used services are handled by intermediaries rather than reused in response to later requests that are equivalent and likely to result in a response directly by each client [6]. identical to that in the cache if the request were to be forwarded to the server. An example

3.4.3 Client-Stateless-Server (CSS) system that makes effective use of this style is Sun Microsystems’ NFS [115].

The client-stateless-server style derives from client-server with the additional constraint The advantage of adding cache components is that they have the potential to partially that no session state is allowed on the server component. Each request from client to or completely eliminate some interactions, improving efficiency and user-perceived server must contain all of the information necessary to understand the request, and cannot performance. take advantage of any stored context on the server. Session state is kept entirely on the 3.4.5 Layered-Client-Cache-Stateless-Server (LC$SS) client. The layered-client-cache-stateless-server style derives from both layered-client-server and These constraints improve the properties of visibility, reliability, and scalability. client-cache-stateless-server through the addition of proxy and/or gateway components. Visibility is improved because a monitoring system does not have to look beyond a single An example system that uses an LC$SS style is the Internet domain name system (DNS). request datum in order to determine the full nature of the request. Reliability is improved The advantages and disadvantages of LC$SS are simply a combination of those for because it eases the task of recovering from partial failures [133]. Scalability is improved LCS and C$SS. However, note that we don’t count the contributions of the CS style twice,

since the benefits are not additive if they come from the same ancestral derivation.

47 48 3.4.6 Remote Session (RS) The advantages of remote data access are that a large data set can be iteratively

The remote session style is a variant of client-server that attempts to minimize the reduced on the server side without transmitting it across the network, improving complexity, or maximize the reuse, of the client components rather than the server efficiency, and visibility is improved by using a standard query language. The component. Each client initiates a session on the server and then invokes a series of disadvantages are that the client needs to understand the same database manipulation services on the server, finally exiting the session. Application state is kept entirely on the concepts as the server implementation (lacking simplicity) and storing application context server. This style is typically used when it is desired to access a remote service using a on the server decreases scalability. Reliability also suffers, since partial failure can leave generic client (e.g., TELNET [106]) or via an interface that mimics a generic client (e.g., the workspace in an unknown state. Transaction mechanisms (e.g., two-phase commit)

FTP [107]). can be used to fix the reliability problem, though at a cost of added complexity and

The advantages of the remote session style are that it is easier to centrally maintain the interaction overhead. interface at the server, reducing concerns about inconsistencies in deployed clients when 3.5 Mobile Code Styles functionality is extended, and improves efficiency if the interactions make use of extended Mobile code styles use mobility in order to dynamically change the distance between the session context on the server. The disadvantages are that it reduces scalability of the processing and source of data or destination of results. These styles are comprehensively server, due to the stored application state, and reduces visibility of interactions, since a examined in Fuggetta et al. [50]. A site abstraction is introduced at the architectural level, monitor would have to know the complete state of the server. as part of the active configuration, in order to take into account the location of the different

3.4.7 Remote Data Access (RDA) components. Introducing the concept of location makes it possible to model the cost of an

The remote data access style [131] is a variant of client-server that spreads the application interaction between components at the design level. In particular, an interaction between state across both client and server. A client sends a database query in a standard format, components that share the same location is considered to have negligible cost when such as SQL, to a remote server. The server allocates a workspace and performs the query, compared to an interaction involving communication through the network. By changing which may result in a very large data set. The client can then make further operations upon its location, a component may improve the proximity and quality of its interaction, the result set (such as table joins) or retrieve the result one piece at a time. The client must reducing interaction costs and thereby improving efficiency and user-perceived know about the data structure of the service to build structure-dependent queries. performance.

49 50 In all of the mobile code styles, a data element is dynamically transformed into a reduced due to the need to manage the evaluation environment, but that may be component. Fuggetta et al. [50] use an analysis that compares the code’s size as a data compensated in some cases as a result of simplifying the static functionality. element to the savings in normal data transfer in order to determine whether mobility is 3.5.2 Remote Evaluation (REV) desirable for a given action. This would be impossible to model from an architectural In the remote evaluation style [50], derived from the client-server and virtual machine standpoint if the definition of software architecture excludes data elements. styles, a client component has the know-how necessary to perform a service, but lacks the

resources (CPU cycles, data source, etc.) required, which happen to be located at a remote

Style Derivation Net Perform. Perform. UP Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability site. Consequently, the client sends the know-how to a server component at the remote VM ±+ −+ REV CS+VM +−± ++ −+− site, which in turn executes the code using the resources available there. The results of that COD CS+VM +++±++− LCODC$SS LC$SS+COD −+++++4++±++++ ++±++ execution are then sent back to the client. The remote evaluation style assumes that the MA REV+COD +++ ± ++++ − + provided code will be executed in a sheltered environment, such that it won’t impact other Table 3-4. Evaluation of Mobile Code Styles for Network-based Hypermedia clients of the same server aside from the resources being used.

3.5.1 Virtual Machine (VM) The advantages of remote evaluation include the ability to customize the server

Underlying all of the mobile code styles is the notion of a virtual machine, or interpreter, component’s services, which provides for improved extensibility and customizability, and style [53]. The code must be executed in some fashion, preferably within a controlled better efficiency when the code can adapt its actions to the environment inside the server environment to satisfy security and reliability concerns, which is exactly what the virtual (as opposed to the client making a series of interactions to do the same). Simplicity is machine style provides. It is not, in itself, a network-based style, but it is commonly used reduced due to the need to manage the evaluation environment, but that may be as such when combined with a component in the client-server style (REV and COD compensated in some cases as a result of simplifying the static server functionality. styles). Scalability is reduced; this can be improved with the server’s management of the

Virtual machines are commonly used as the engine for scripting languages, including execution environment (killing long-running or resource-intensive code when resources general purpose languages like Perl [134] and task-specific languages like PostScript [2]. are tight), but the management function itself leads to difficulties regarding partial failure

The primary benefits are the separation between instruction and implementation on a and reliability. The most significant limitation, however, is the lack of visibility due to the particular platform (portability) and ease of extensibility. Visibility is reduced because it is hard to know what an executable will do simply by looking at the code. Simplicity is

51 52 client sending code instead of standardized queries. Lack of visibility leads to obvious advantages of the LC$SS style. An example is the HotJava Web browser [java.sun.com], deployment problems if the server cannot trust the clients. 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 3.5.3 Code on Demand (COD) COD and LC$SS. We could go further and discuss the combination of COD with other CS In the code-on-demand style [50], a client component has access to a set of resources, but styles, but this survey is not intended to be exhaustive (nor exhausting). not the know-how on how to process them. It sends a request to a remote server for the code representing that know-how, receives that code, and executes it locally. 3.5.5 Mobile Agent (MA)

The advantages of code-on-demand include the ability to add features to a deployed In the mobile agent style [50], an entire computational component is moved to a remote client, which provides for improved extensibility and configurability, and better user- site, along with its state, the code it needs, and possibly some data required to perform the perceived performance and efficiency when the code can adapt its actions to the client’s task. This can be considered a derivation of the remote evaluation and code-on-demand environment and interact with the user locally rather than through remote interactions. styles, since the mobility works both ways.

Simplicity is reduced due to the need to manage the evaluation environment, but that may The primary advantage of the mobile agent style, beyond those already described for be compensated in some cases as a result of simplifying the client’s static functionality. REV and COD, is that there is greater dynamism in the selection of when to move the

Scalability of the server is improved, since it can off-load work to the client that would code. An application can be in the midst of processing information at one location when it otherwise have consumed its resources. Like remote evaluation, the most significant decides to move to another location, presumably in order to reduce the distance between it limitation is the lack of visibility due to the server sending code instead of simple data. and the next set of data it wishes to process. In addition, the reliability problem of partial

Lack of visibility leads to obvious deployment problems if the client cannot trust the failure is reduced because the application state is in one location at a time [50]. servers.

3.5.4 Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)

As an example of how some architectures are complementary, consider the addition of code-on-demand to the layered-client-cache-stateless-server style discussed above. Since the code can be treated as just another data element, this does not interfere with the

53 54 3.6 Peer-to-Peer Styles 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 Style Derivation Net Perform. UP Perform. Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability EBI +− −±++ ++− − for events of interest to them. Of course, this immediately leads to scalability issues with C2 EBI+LCS −+ ++++ +++±+± regard to the number of notifications, event storms as other components broadcast as a DO CS+CS − + ++ ++− − BDO DO+LCS − − ++ + + ++ − + result of events caused by that notification, and a single point of failure in the notification Table 3-5. Evaluation of Peer-to-Peer Styles for Network-based Hypermedia delivery system. This can be ameliorated though the use of layered systems and filtering 3.6.1 Event-based Integration (EBI) of events, at the cost of simplicity. The event-based integration style, also known as the implicit invocation or event system Other disadvantages of EBI systems are that it can be hard to anticipate what will style, reduces coupling between components by removing the need for identity on the happen in response to an action (poor understandability) and event notifications are not connector interface. Instead of invoking another component directly, a component can suitable for exchanging large-grain data [53]. Also, there is no support for recovery from announce (or broadcast) one or more events. Other components in a system can register partial failure. interest in that type of event and, when the event is announced, the system itself invokes all of the registered components [53]. Examples include the Model-View-Controller 3.6.2 C2 paradigm in Smalltalk-80 [72] and the integration mechanisms of many software The C2 architectural style [128] is directed at supporting large-grain reuse and flexible engineering environments, including Field [113], SoftBench [29], and Polylith [110]. composition of system components by enforcing substrate independence. It does so by

The event-based integration style provides strong support for extensibility through the combining event-based integration with layered-client-server. Asynchronous notification ease of adding new components that listen for events, for reuse by encouraging a general messages going down, and asynchronous request messages going up, are the sole means event interface and integration mechanism, and for evolution by allowing components to of intercomponent communication. This enforces loose coupling of dependency on higher be replaced without affecting the interfaces of other components [53]. Like pipe-and-filter layers (service requests may be ignored) and zero coupling with lower levels (no systems, a higher-level configuring architecture is needed for the “invisible hand” that knowledge of notification usage), improving control over the system without losing most places components on the event interface. Most EBI systems also include explicit of the advantages of EBI. invocation as a complementary form of interaction [53]. For applications that are

55 56 Notifications are announcements of a state change within a component. C2 does not advantageous in terms of keeping the state where it is most likely to be up-to-date, but has constrain what should be included with a notification: a flag, a delta of state change, or a the disadvantage in that it is difficult to obtain an overall view of system activity (poor complete state representation are all possibilities. A connector’s primary responsibility is visibility). the routing and broadcasting of messages; its secondary responsibility is message filtering. In order for one object to interact with another, it must know the identity of that other

The introduction of layered filtering of messages solves the EBI problems with scalability, object. When the identity of an object changes, it is necessary to modify all other objects while improving evolvability and reusability as well. Heavyweight connectors that include that explicitly invoke it [53]. There must be some controller object that is responsible for monitoring capabilities can be used to improve visibility and reduce the reliability maintaining the system state in order to complete the application requirements. Central problems of partial failure. issues for distributed object systems include: object management, object interaction

management, and resource management [31]. 3.6.3 Distributed Objects Object systems are designed to isolate the data being processed. As a consequence, The distributed objects style organizes a system as a set of components interacting as data streaming is not supported in general. However, this does provide better support for peers. An object is an entity that encapsulates some private state information or data, a set object mobility when combined with the mobile agent style. of associated operations or procedures that manipulate the data, and possibly a thread of control, so that collectively they can be considered a single unit [31]. In general, an 3.6.4 Brokered Distributed Objects object’s state is completely hidden and protected from all other objects. The only way it In order to reduce the impact of identity, modern distributed object systems typically use can be examined or modified is by making a request or invocation on one of the object’s one or more intermediary styles to facilitate communication. This includes event-based publicly accessible operations. This creates a well-defined interface for each object, integration and brokered client/server [28]. The brokered distributed object style enabling the specification of an object’s operations to be made public while at the same introduces name resolver components whose purpose is to answer client object requests time keeping the implementation of its operations and the representation of its state for general service names with the specific name of an object that will satisfy the request. information private, thus improving evolvability. Although improving reusability and evolvability, the extra level of indirection requires

An operation may invoke other operations, possibly on other objects. These operations additional network interactions, reducing efficiency and user-perceived performance. may in turn make invocations on others, and so on. A chain of related invocations is referred to as an action [31]. State is distributed among the objects. This can be

57 58 Brokered distributed object systems are currently dominated by the industrial classification tables for each type of communication problem. Example problem areas standards development of CORBA within the OMG [97] and the international standards would include, among others, large grain data retrieval, remote information monitoring, development of Open Distributed Processing (ODP) within ISO/IEC [66]. search, remote control systems, and distributed processing.

In spite of all the interest associated with distributed objects, they fare poorly when A second limitation is with the grouping of architectural properties. In some cases, it is compared to most other network-based architectural styles. They are best used for better to identify the specific aspects of, for example, understandability and verifiability applications that involve the remote invocation of encapsulated services, such as hardware induced by an architectural style, rather than lumping them together under the rubric of devices, where the efficiency and frequency of network interactions is less a concern. simplicity. This is particularly the case for styles which might improve verifiability at the

expense of understandability. However, the more abstract notion of a property also has 3.7 Limitations value as a single metric, since we do not want to make the classification so specific that no Each architectural style promotes a certain type of interaction among components. When two styles impact the same category. One solution would be a classification that presented components are distributed across a wide-area network, use or misuse of the network both the specific properties and a summary property. drives application usability. By characterizing styles by their influence on architectural Regardless, this initial survey and classification is a necessary prerequisite to any properties, and particularly on the network-based application performance of a distributed further classifications that might address its limitations. 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 3.8 Related Work classification. 3.8.1 Classification of Architectural Styles and Patterns

The first limitation is that the evaluation is specific to the needs of distributed The area of research most directly related to this chapter is the identification and hypermedia. For example, many of the good qualities of the pipe-and-filter style disappear classification of architectural styles and architecture-level patterns. if the communication is fine-grained control messages, and are not applicable at all if the Shaw [117] describes a few architectural styles, later expanded in Garlan and Shaw communication requires user interactivity. Likewise, layered caching only adds to latency, [53]. A preliminary classification of these styles is presented in Shaw and Clements [122] without any benefit, if none of the responses to client requests are cacheable. This type of and repeated in Bass et al. [9], in which a two-dimensional, tabular classification strategy distinction does not appear in the classification, and is only addressed informally in the is used with control and data issues as the primary axes, organized by the following discussion of each style. I believe this limitation can be overcome by creating separate categories of features: which kinds of components and connectors are used in the style;

59 60 how control is shared, allocated, and transferred among the components; how data is Zimmer [137] organizes design patterns using a graph based on their relationships, communicated through the system; how data and control interact; and, what type of making it easier to understand the overall structure of the patterns in the Gamma et al. [51] reasoning is compatible with the style. The primary purpose of the taxonomy is to identify catalog. However, the patterns classified are not architectural patterns, and the style characteristics, rather than to assist in their comparison. It concludes with a small set classification is based exclusively on derivation or uses relationships rather than on of “rules of thumb” as a form of design guidance architectural properties.

Unlike this chapter, the Shaw and Clements [122] classification does not assist in 3.8.2 Distributed Systems and Programming Paradigms evaluating designs in a way that is useful to an application designer. The problem is that Andrews [6] surveys how processes in a distributed program interact via message passing. the purpose of building software is not to build a specific shape, topology or component He defines concurrent programs, distributed programs, kinds of processes in a distributed type, so organizing the classification in that fashion does not help a designer find a style program (filters, clients, servers, peers), interaction paradigms, and communication that corresponds to their needs. It also mixes the essential differences among styles with channels. Interaction paradigms represent the communication aspects of software other issues which have only incidental significance, and obscures the derivation architectural styles. He describes paradigms for one-way data flow through networks of relationships among styles. Furthermore, it does not focus on any particular type of filters (pipe-and-filter), client-server, heartbeat, probe/echo, broadcast, token passing, architecture, such as network-based applications. Finally, it does not describe how styles replicated servers, and replicated workers with bag of tasks. However, the presentation is can be combined, nor the effect of their combination. from the perspective of multiple processes cooperating on a single task, rather than Buschmann and Meunier [27] describe a classification scheme that organizes patterns general network-based architectural styles. according to granularity of abstraction, functionality, and structural principles. The Sullivan and Notkin [126] provide a survey of implicit invocation research and granularity of abstraction separates patterns into three categories: architectural describe its application to improving the evolution quality of software tool suites. Barrett frameworks (templates for architectures), design patterns, and idioms. Their classification et al. [8] present a survey of event-based integration mechanisms by building a framework addresses some of the same issues as this dissertation, such as separation of concerns and for comparison and then seeing how some systems fit within that framework. Rosenblum structural principles that lead to architectural properties, but only covers two of the and Wolf [114] investigate a design framework for Internet-scale event notification. All architectural styles described here. Their classification is considerably expanded in are concerned with the scope and requirements of an EBI style, rather than providing Buschmann et al. [28] with more extensive discussion of architectural patterns and their solutions for network-based systems. relation to software architecture.

61 62 Fuggetta et al. [50] provide a thorough examination and classification of mobile code 3.9 Summary paradigms. This chapter builds upon their work to the extent that I compare the mobile This chapter has presented a survey of common architectural styles for network-based code styles with other network-capable styles, and place them within a single framework application software within a classification framework that evaluates each style according and set of architectural definitions. to the architectural properties it would induce if applied to an architecture for a

prototypical network-based hypermedia system. The overall classification is summarized 3.8.3 Middleware below in Table 3-6. Bernstein [22] defines middleware as a distributed system service that includes standard The next chapter uses the insight garnered from this survey and classification to programming interfaces and protocols. These services are called middleware because they hypothesize methods for developing and evaluating an architectural style to guide the act as a layer above the OS and networking software and below industry-specific design of improvements for the modern World Wide Web architecture. 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 64 CHAPTER 4 Designing the Web Architecture: Problems and Insights Style Derivation Net Perform. UP Perform. Efficiency Scalability Simplicity Evolvability Extensibility Customiz. Configur. Reusability Visibility Portability Reliability PF ± +++ ++ UPF PF − ± ++ + + ++ ++ + RR ++ + + This chapter presents the requirements of the World Wide Web architecture and the $RR ++++ problems faced in designing and evaluating proposed improvements to its key CS +++ LS −++ ++ communication protocols. I use the insights garnered from the survey and classification of LCS CS+LS − +++++ + + CSS CS −++++ ++ architectural styles for network-based hypermedia systems to hypothesize methods for C$SS CSS+$ −++++++ + + LC$SS LCS+C$SS −±++++++++ ++++ developing an architectural style that would be used to guide the design of improvements RS CS +−++ − for the modern Web architecture. RDA CS +−− + − VM ±+ −+ +−± ++ −+− REV CS+VM 4.1 WWW Application Domain Requirements COD CS+VM +++±++− −+++++4++±++++ ++±++ LCODC$SS LC$SS+COD Berners-Lee [20] writes that the “Web’s major goal was to be a shared information space MA REV+COD +++ ± ++++ − + EBI +− −±++ ++− − through which people and machines could communicate.” What was needed was a way C2 EBI+LCS − + ++++ +++±+ ± DO CS+CS − + ++ ++− − for people to store and structure their own information, whether permanent or ephemeral BDO DO+LCS − − ++ + + ++ − + in nature, such that it could be usable by themselves and others, and to be able to reference Table 3-6. Evaluation Summary 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 to

65 66 this structured information, available on as many platforms as possible, and incrementally were encouraged to collaborate in the development of information sources, references deployable as new people and organizations joined the project. 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. 4.1.1 Low Entry-barrier Simplicity was also a goal for the sake of application developers. Since all of the Since participation in the creation and structuring of information was voluntary, a low protocols were defined as text, communication could be viewed and interactively tested entry-barrier was necessary to enable sufficient adoption. This applied to all users of the using existing network tools. This enabled early adoption of the protocols to take place in Web architecture: readers, authors, and application developers. spite of the lack of standards. 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 4.1.2 Extensibility hypermedia relationships (links) allows for unlimited structuring, and the direct While simplicity makes it possible to deploy an initial implementation of a distributed manipulation of links allows the complex relationships within the information to guide the system, extensibility allows us to avoid getting stuck forever with the limitations of what reader through an application. Since information within large databases is often much was deployed. Even if it were possible to build a software system that perfectly matches easier to access via a search interface rather than browsing, the Web also incorporated the the requirements of its users, those requirements will change over time just as society ability to perform simple queries by providing user-entered data to a service and rendering changes over time. A system intending to be as long-lived as the Web must be prepared the result as hypermedia. for change.

For authors, the primary requirement was that partial availability of the overall system 4.1.3 Distributed Hypermedia must not prevent the authoring of content. The hypertext authoring language needed to be Hypermedia is defined by the presence of application control information embedded simple and capable of being created using existing editing tools. Authors were expected to within, or as a layer above, the presentation of information. Distributed hypermedia allows keep such things as personal research notes in this format, whether directly connected to the presentation and control information to be stored at remote locations. By its nature, the Internet or not, so the fact that some referenced information was unavailable, either user actions within a distributed hypermedia system require the transfer of large amounts temporarily or permanently, could not be allowed to prevent the reading and authoring of of data from where the data is stored to where it is used. Thus, the Web architecture must information that was available. For similar reasons, it was necessary to be able to create be designed for large-grain data transfer. references to information before the target of that reference was available. Since authors

67 68 The usability of hypermedia interaction is highly sensitive to user-perceived latency: pointers,” an identifier for each data element that references them, since the number of the time between selecting a link and the rendering of a usable result. Since the Web’s references to a resource is proportional to the number of people interested in that information sources are distributed across the global Internet, the architecture needs to information. Particularly newsworthy information can also lead to “flash crowds”: sudden minimize network interactions (round-trips within the data transfer protocols). spikes in access attempts as news of its availability spreads across the world.

Security of the architectural elements, and the platforms on which they operate, also 4.1.4 Internet-scale becomes a significant concern. Multiple organizational boundaries implies that multiple The Web is intended to be an Internet-scale distributed hypermedia system, which means trust boundaries could be present in any communication. Intermediary applications, such considerably more than just geographical dispersion. The Internet is about interconnecting as firewalls, should be able to inspect the application interactions and prevent those information networks across multiple organizational boundaries. Suppliers of information outside the security policy of the organization from being acted upon. The participants in services must be able to cope with the demands of anarchic scalability and the an application interaction should either assume that any information received is untrusted, independent deployment of software components. or require some additional authentication before trust can be given. This requires that the 4.1.4.1 Anarchic Scalability architecture be capable of communicating authentication data and authorization controls. Most software systems are created with the implicit assumption that the entire system is However, since authentication degrades scalability, the architecture’s default operation under the control of one entity, or at least that all entities participating within a system are should be limited to actions that do not need trusted data: a safe set of operations with acting towards a common goal and not at cross-purposes. Such an assumption cannot be well-defined semantics. safely made when the system runs openly on the Internet. Anarchic scalability refers to the 4.1.4.2 Independent Deployment need for architectural elements to continue operating when they are subjected to an Multiple organizational boundaries also means that the system must be prepared for unanticipated load, or when given malformed or maliciously constructed data, since they gradual and fragmented change, where old and new implementations co-exist without may be communicating with elements outside their organizational control. The preventing the new implementations from making use of their extended capabilities. architecture must be amenable to mechanisms that enhance visibility and scalability. Existing architectural elements need to be designed with the expectation that later The anarchic scalability requirement applies to all architectural elements. Clients architectural features will be added. Likewise, older implementations need to be easily cannot be expected to maintain knowledge of all servers. Servers cannot be expected to identified so that legacy behavior can be encapsulated without adversely impacting newer retain knowledge of state across requests. Hypermedia data elements cannot retain “back- architectural elements. The architecture as a whole must be designed to ease the

69 70 deployment of architectural elements in a partial, iterative fashion, since it is not possible Working groups within the Internet Engineering Taskforce were formed to work on to force deployment in an orderly manner. 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 4.2 Problem consistently implemented in the early Web architecture, identify problems within that In late 1993, it became clear that more than just researchers would be interested in the architecture, and then specify a set of standards to solve those problems. This presented us Web. Adoption had occurred first in small research groups, spread to on-campus dorms, with a challenge: how do we introduce a new set of functionality to an architecture that is clubs, and personal home pages, and later to the institutional departments for campus already widely deployed, and how do we ensure that its introduction does not adversely information. When individuals began publishing their personal collections of information, impact, or even destroy, the architectural properties that have enabled the Web to on whatever topics they might feel fanatic about, the social network-effect launched an succeed? 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 4.3 Approach would be irresistible to businesses. The early Web architecture was based on solid principles—separation of concerns,

Although elated by its success, the Internet developer community became concerned simplicity, and generality—but lacked an architectural description and rationale. The that the rapid growth in the Web’s usage, along with some poor network characteristics of design was based on a set of informal hypertext notes [14], two early papers oriented early HTTP, would quickly outpace the capacity of the Internet infrastructure and lead to a towards the user community [12, 13], and archived discussions on the Web developer general collapse. This was worsened by the changing nature of application interactions on community mailing list ( [email protected] ). In reality, however, the only true the Web. Whereas the initial protocols were designed for single request-response pairs, description of the early Web architecture was found within the implementations of new sites used an increasing number of in-line images as part of the content of Web pages, libwww (the CERN protocol library for clients and servers), Mosaic (the NCSA browser resulting in a different interaction profile for browsing. The deployed architecture had client), and an assortment of other implementations that interoperated with them. significant limitations in its support for extensibility, shared caching, and intermediaries, An architectural style can be used to define the principles behind the Web architecture which made it difficult to develop ad-hoc solutions to the growing problems. At the same such that they are visible to future architects. As discussed in Chapter 1, a style is a named time, commercial competition within the software market led to an influx of new and set of constraints on architectural elements that induces the set of properties desired of the occasionally contradictory feature proposals for the Web’s protocols.

71 72 architecture. The first step in my approach, therefore, is to identify the constraints placed Hypothesis III: Proposals to modify the Web architecture can be compared to the updated WWW architectural style and analyzed for within the early Web architecture that are responsible for its desirable properties. conflicts prior to deployment.

Hypothesis I: The design rationale behind the WWW architecture can Finally, the updated Web architecture, as defined by the revised protocol standards that be described by an architectural style consisting of the set of constraints applied to the elements within the Web architecture. 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 Additional constraints can be applied to an architectural style in order to extend the set of that make up the majority of Web applications. This included my direct participation in properties induced on instantiated architectures. The next step in my approach is to software development for the Apache HTTP server project and the libwww-perl client identify the properties desirable in an Internet-scale distributed hypermedia system, select library, as well as indirect participation in other projects by advising the developers of the additional architectural styles that induce those properties, and combine them with the W3C libwww and jigsaw projects, the Netscape Navigator, Lynx, and MSIE browsers, early Web constraints to form a new, hybrid architectural style for the modern Web and dozens of other implementations, as part of the IETF discourse. architecture. Although I have described this approach as a single sequence, it is actually applied in a Hypothesis II: Constraints can be added to the WWW architectural style to derive a new hybrid style that better reflects the desired non-sequential, iterative fashion. That is, over the past six years I have been constructing properties of a modern Web architecture. 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, Using the new architectural style as a guide, we can compare proposed extensions and others have suggested the addition of features to the architecture that were outside the modifications to the Web architecture against the constraints within the style. Conflicts scope of my then-current model style, but not in conflict with it, which resulted in going indicate that the proposal would violate one or more of the design principles behind the back and revising the architectural constraints to better reflect the improved architecture. Web. In some cases, the conflict could be removed by requiring the use of a specific The goal has always been to maintain a consistent and correct model of how I intend the indicator whenever the new feature is used, as is often done for HTTP extensions that Web architecture to behave, so that it could be used to guide the protocol standards that impact the default cacheability of a response. For severe conflicts, such as a change in the define appropriate behavior, rather than to create an artificial model that would be limited interaction style, the same functionality would either be replaced with a design more to the constraints originally imagined when the work began. conducive to the Web’s style, or the proposer would be told to implement the functionality as a separate architecture running in parallel to the Web.

73 74 4.4 Summary CHAPTER 5

This chapter presented the requirements of the World Wide Web architecture and the Representational State Transfer (REST) problems faced in designing and evaluating proposed improvements to its key communication protocols. The challenge is to develop a method for designing This chapter introduces and elaborates the Representational State Transfer (REST) improvements to an architecture such that the improvements can be evaluated prior to architectural style for distributed hypermedia systems, describing the software engineering their deployment. My approach is to use an architectural style to define and improve the principles guiding REST and the interaction constraints chosen to retain those principles, design rationale behind the Web’s architecture, to use that style as the acid test for proving while contrasting them to the constraints of other architectural styles. REST is a hybrid proposed extensions prior to their deployment, and to deploy the revised architecture via style derived from several of the network-based architectural styles described in Chapter 3 direct involvement in the software development projects that have created the Web’s and combined with additional constraints that define a uniform connector interface. The infrastructure. software architecture framework of Chapter 1 is used to define the architectural elements

The next chapter introduces and elaborates the Representational State Transfer of REST and examine sample process, connector, and data views of prototypical

(REST) architectural style for distributed hypermedia systems, as it has been developed to architectures. 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 5.1 Deriving REST component interactions, generality of interfaces, independent deployment of components, The design rationale behind the Web architecture can be described by an architectural and intermediary components to reduce interaction latency, enforce security, and style consisting of the set of constraints applied to elements within the architecture. By encapsulate legacy systems. 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.

75 76 Server Client WWW

Figure 5-2. Client-Server

Figure 5-1. Null Style 5.1.2 Client-Server

5.1.1 Starting with the Null Style The first constraints added to our hybrid style are those of the client-server architectural

There are two common perspectives on the process of architectural design, whether it be style (Figure 5-2), described in Section 3.4.1. Separation of concerns is the principle for buildings or for software. The first is that a designer starts with nothing—a blank slate, behind the client-server constraints. By separating the user interface concerns from the whiteboard, or drawing board—and builds-up an architecture from familiar components data storage concerns, we improve the portability of the user interface across multiple until it satisfies the needs of the intended system. The second is that a designer starts with platforms and improve scalability by simplifying the server components. Perhaps most the system needs as a whole, without constraints, and then incrementally identifies and significant to the Web, however, is that the separation allows the components to evolve applies constraints to elements of the system in order to differentiate the design space and independently, thus supporting the Internet-scale requirement of multiple organizational allow the forces that influence system behavior to flow naturally, in harmony with the domains. system. Where the first emphasizes creativity and unbounded vision, the second 5.1.3 Stateless emphasizes restraint and understanding of the system context. REST has been developed We next add a constraint to the client-server interaction: communication must be stateless using the latter process. Figures 5-1 through 5-8 depict this graphically in terms of how the in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such applied constraints would differentiate the process view of an architecture as the that each request from client to server must contain all of the information necessary to 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 Server Client boundaries between components. It is the starting point for our description of REST.

Figure 5-3. Client-Stateless-Server

77 78 understand the request, and cannot take advantage of any stored context on the server. $ Session state is therefore kept entirely on the client. Server Client This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request Client+Cache datum in order to determine the full nature of the request. Reliability is improved because $ it eases the task of recovering from partial failures [133]. Scalability is improved because Figure 5-4. Client-Cache-Stateless-Server not having to store state between requests allows the server component to quickly free The advantage of adding cache constraints is that they have the potential to partially or resources, and further simplifies implementation because the server doesn’t have to completely eliminate some interactions, improving efficiency, scalability, and user- manage resource usage across requests. perceived performance by reducing the average latency of a series of interactions. The Like most architectural choices, the stateless constraint reflects a design trade-off. The trade-off, however, is that a cache can decrease reliability if stale data within the cache disadvantage is that it may decrease network performance by increasing the repetitive data differs significantly from the data that would have been obtained had the request been sent (per-interaction overhead) sent in a series of requests, since that data cannot be left on the directly to the server. server in a shared context. In addition, placing the application state on the client-side The early Web architecture, as portrayed by the diagram in Figure 5-5 [11], was reduces the server’s control over consistent application behavior, since the application defined by the client-cache-stateless-server set of constraints. That is, the design rationale becomes dependent on the correct implementation of semantics across multiple client presented for the Web architecture prior to 1994 focused on stateless client-server versions. 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 5.1.4 Cache constrain the interface to a consistent set of semantics for all resources. Instead, the Web In order to improve network efficiency, we add cache constraints to form the client-cache- relied on the use of a common client-server implementation library (CERN libwww) to stateless-server style of Section 3.4.4 (Figure 5-4). Cache constraints require that the data maintain consistency across Web applications. within a response to a request be implicitly or explicitly labeled as cacheable or non- Developers of Web implementations had already exceeded the early design. In cacheable. If a response is cacheable, then a client cache is given the right to reuse that addition to static documents, requests could identify services that dynamically generated response data for later, equivalent requests. responses, such as image-maps [Kevin Hughes] and server-side scripts [Rob McCool].

79 80 Browsers dumb PC Mac X NeXT $ orb

Addressing scheme + Common protocol + Format negotiation $

Client Connector: Client+Cache: $ Server Connector: Server+Cache: $ elp ga H te S w

V D gat IN ew F HTTP FTP Gopher NNTP a Figure 5-6. Uniform-Client-Cache-Stateless-Server X y server server server server IS gatew A a W y

independent evolvability. The trade-off, though, is that a uniform interface degrades Internet News efficiency, since information is transferred in a standardized form rather than one which is Servers/Gateways specific to an application’s needs. The REST interface is designed to be efficient for large- © 1992 Tim Berners-Lee, Robert Cailliau , Jean-François Groff, C.E.R.N.

Figure 5-5. Early WWW Architecture Diagram 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. Work had also begun on intermediary components, in the form of proxies [79] and shared In order to obtain a uniform interface, multiple architectural constraints are needed to caches [59], but extensions to the protocols were needed in order for them to communicate guide the behavior of components. REST is defined by four interface constraints: reliably. The following sections describe the constraints added to the Web’s architectural identification of resources; manipulation of resources through representations; self- style in order to guide the extensions that form the modern Web architecture. descriptive messages; and, hypermedia as the engine of application state. These

5.1.5 Uniform Interface constraints will be discussed in Section 5.2.

The central feature that distinguishes the REST architectural style from other network- 5.1.6 Layered System based styles is its emphasis on a uniform interface between components (Figure 5-6). By In order to further improve behavior for Internet-scale requirements, we add layered applying the software engineering principle of generality to the component interface, the system constraints (Figure 5-7). As described in Section 3.4.2, the layered system style overall system architecture is simplified and the visibility of interactions is improved. allows an architecture to be composed of hierarchical layers by constraining component Implementations are decoupled from the services they provide, which encourages behavior such that each component cannot “see” beyond the immediate layer with which

81 82 $ $ orb $ $ orb $ $

Client Connector: Client+Cache: $ Server Connector: Server+Cache: $ Client Connector: Client+Cache: $ Server Connector: Server+Cache: $

Figure 5-7. Uniform-Layered-Client-Cache-Stateless-Server Figure 5-8. REST they are interacting. By restricting knowledge of the system to a single layer, we place a hypermedia interaction can each be processed like a data-flow network, with filter bound on the overall system complexity and promote substrate independence. Layers can components selectively applied to the data stream in order to transform the content as it be used to encapsulate legacy services and to protect new services from legacy clients, passes [26]. Within REST, intermediary components can actively transform the content of simplifying components by moving infrequently used functionality to a shared messages because the messages are self-descriptive and their semantics are visible to intermediary. Intermediaries can also be used to improve system scalability by enabling intermediaries. load balancing of services across multiple networks and processors. 5.1.7 Code-On-Demand The primary disadvantage of layered systems is that they add overhead and latency to The final addition to our constraint set for REST comes from the code-on-demand style of the processing of data, reducing user-perceived performance [32]. For a network-based Section 3.5.3 (Figure 5-8). REST allows client functionality to be extended by system that supports cache constraints, this can be offset by the benefits of shared caching downloading and executing code in the form of applets or scripts. This simplifies clients at intermediaries. Placing shared caches at the boundaries of an organizational domain can by reducing the number of features required to be pre-implemented. Allowing features to result in significant performance benefits [136]. Such layers also allow security policies to be downloaded after deployment improves system extensibility. However, it also reduces be enforced on data crossing the organizational boundary, as is required by firewalls [79]. visibility, and thus is only an optional constraint within REST. The combination of layered system and uniform interface constraints induces The notion of an optional constraint may seem like an oxymoron. However, it does architectural properties similar to those of the uniform pipe-and-filter style have a purpose in the architectural design of a system that encompasses multiple (Section 3.2.2). Although REST interaction is two-way, the large-grain data flows of organizational boundaries. It means that the architecture only gains the benefit (and suffers

83 84 easier to understand the rationale behind their selection. Figure 5-9 depicts the derivation layered pr replicated og of REST’s constraints graphically in terms of the network-based architectural styles ram uniform interface ma separated bl e examined in Chapter 3. RR CS LS VM U i nt er pr m oc ed on-demand stateless es ia mobile simple si te ng visible 5.2 REST Architectural Elements $ CSS LCS COD The Representational State Transfer (REST) style is an abstraction of the architectural reliable shared extensible reusable elements within a distributed hypermedia system. REST ignores the details of component cacheable scalable multi- C$SS LC$SS LCODC$SS REST org. implementation and protocol syntax in order to focus on the roles of components, the

Figure 5-9. REST Derivation by Style Constraints constraints upon their interaction with other components, and their interpretation of

significant data elements. It encompasses the fundamental constraints upon components, the disadvantages) of the optional constraints when they are known to be in effect for some connectors, and data that define the basis of the Web architecture, and thus the essence of realm of the overall system. For example, if all of the client software within an its behavior as a network-based application. organization is known to support Java applets [45], then services within that organization can be constructed such that they gain the benefit of enhanced functionality via 5.2.1 Data Elements downloadable Java classes. At the same time, however, the organization’s firewall may Unlike the distributed object style [31], where all data is encapsulated within and hidden prevent the transfer of Java applets from external sources, and thus to the rest of the Web by the processing components, the nature and state of an architecture’s data elements is a it will appear as if those clients do not support code-on-demand. An optional constraint key aspect of REST. The rationale for this design can be seen in the nature of distributed allows us to design an architecture that supports the desired behavior in the general case, hypermedia. When a link is selected, information needs to be moved from the location but with the understanding that it may be disabled within some contexts. where it is stored to the location where it will be used by, in most cases, a human reader.

This is unlike many other distributed processing paradigms [6, 50], where it is possible, 5.1.8 Style Derivation Summary and usually more efficient, to move the “processing agent” (e.g., mobile code, stored REST consists of a set of architectural constraints chosen for the properties they induce on procedure, search expression, etc.) to the data rather than move the data to the processor. candidate architectures. Although each of these constraints can be considered in isolation, A distributed hypermedia architect has only three fundamental options: 1) render the describing them in terms of their derivation from common architectural styles makes it data where it is located and send a fixed-format image to the recipient; 2) encapsulate the

85 86 data with a rendering engine and send both to the recipient; or, 3) send the raw data to the separation of concerns of the client-server style without the server scalability problem, recipient along with metadata that describes the data type, so that the recipient can choose allows information hiding through a generic interface to enable encapsulation and their own rendering engine. evolution of services, and provides for a diverse set of functionality through downloadable

Each option has its advantages and disadvantages. Option 1, the traditional client- feature-engines. server style [31], allows all information about the true nature of the data to remain hidden REST’s data elements are summarized in Table 5-1. within the sender, preventing assumptions from being made about the data structure and Table 5-1. REST Data Elements

Data Element Modern Web Examples making client implementation easier. However, it also severely restricts the functionality resource the intended conceptual target of a hypertext reference of the recipient and places most of the processing load on the sender, leading to scalability resource identifier URL, URN problems. Option 2, the mobile object style [50], provides information hiding while representation HTML document, JPEG image representation metadata media type, last-modified time enabling specialized processing of the data via its unique rendering engine, but limits the resource metadata source link, alternates, vary functionality of the recipient to what is anticipated within that engine and may vastly control data if-modified-since, cache-control increase the amount of data transferred. Option 3 allows the sender to remain simple and scalable while minimizing the bytes transferred, but loses the advantages of information 5.2.1.1 Resources and Resource Identifiers hiding and requires that both sender and recipient understand the same data types. The key abstraction of information in REST is a resource. Any information that can be

REST provides a hybrid of all three options by focusing on a shared understanding of named can be a resource: a document or image, a temporal service (e.g. “today’s weather data types with metadata, but limiting the scope of what is revealed to a standardized in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and interface. REST components communicate by transferring a representation of a resource so on. In other words, any concept that might be the target of an author’s hypertext in a format matching one of an evolving set of standard data types, selected dynamically reference must fit within the definition of a resource. A resource is a conceptual mapping based on the capabilities or desires of the recipient and the nature of the resource. Whether to a set of entities, not the entity that corresponds to the mapping at any particular point in the representation is in the same format as the raw source, or is derived from the source, time. remains hidden behind the interface. The benefits of the mobile object style are More precisely, a resource R is a temporally varying membership function MR(t), approximated by sending a representation that consists of instructions in the standard data which for time t maps to a set of entities, or values, which are equivalent. The values in the format of an encapsulated rendering engine (e.g., Java [45]). REST therefore gains the set may be resource representations and/or resource identifiers. A resource can map to the

87 88 empty set, which allows references to be made to a concept before any realization of that REST uses a resource identifier to identify the particular resource involved in an concept exists — a notion that was foreign to most hypertext systems prior to the Web interaction between components. REST connectors provide a generic interface for

[61]. Some resources are static in the sense that, when examined at any time after their accessing and manipulating the value set of a resource, regardless of how the membership creation, they always correspond to the same value set. Others have a high degree of function is defined or the type of software that is handling the request. The naming variance in their value over time. The only thing that is required to be static for a resource authority that assigned the resource identifier, making it possible to reference the resource, is the semantics of the mapping, since the semantics is what distinguishes one resource is responsible for maintaining the semantic validity of the mapping over time (i.e., from another. ensuring that the membership function does not change).

For example, the “authors’ preferred version” of an academic paper is a mapping Traditional hypertext systems [61], which typically operate in a closed or local whose value changes over time, whereas a mapping to “the paper published in the environment, use unique node or document identifiers that change every time the proceedings of conference X” is static. These are two distinct resources, even if they both information changes, relying on link servers to maintain references separately from the map to the same value at some point in time. The distinction is necessary so that both content [135]. Since centralized link servers are an anathema to the immense scale and resources can be identified and referenced independently. A similar example from multi-organizational domain requirements of the Web, REST relies instead on the author software engineering is the separate identification of a version-controlled source code file choosing a resource identifier that best fits the nature of the concept being identified. when referring to the “latest revision”, “revision number 1.2.7”, or “revision included with Naturally, the quality of an identifier is often proportional to the amount of money spent to the Orange release.” retain its validity, which leads to broken links as ephemeral (or poorly supported)

This abstract definition of a resource enables key features of the Web architecture. information moves or disappears over time.

First, it provides generality by encompassing many sources of information without 5.2.1.2 Representations artificially distinguishing them by type or implementation. Second, it allows late binding REST components perform actions on a resource by using a representation to capture the of the reference to a representation, enabling content negotiation to take place based on current or intended state of that resource and transferring that representation between characteristics of the request. Finally, it allows an author to reference the concept rather components. A representation is a sequence of bytes, plus representation metadata to than some singular representation of that concept, thus removing the need to change all describe those bytes. Other commonly used but less precise names for a representation existing links whenever the representation changes (assuming the author used the right include: document, file, and HTTP message entity, instance, or variant. identifier).

89 90 A representation consists of data, metadata describing the data, and, on occasion, are capable of both. Composite media types can be used to enclose multiple metadata to describe the metadata (usually for the purpose of verifying message integrity). representations in a single message.

Metadata is in the form of name-value pairs, where the name corresponds to a standard The design of a media type can directly impact the user-perceived performance of a that defines the value’s structure and semantics. Response messages may include both distributed hypermedia system. Any data that must be received before the recipient can representation metadata and resource metadata: information about the resource that is not begin rendering the representation adds to the latency of an interaction. A data format that specific to the supplied representation. places the most important rendering information up front, such that the initial information

Control data defines the purpose of a message between components, such as the action can be incrementally rendered while the rest of the information is being received, results in being requested or the meaning of a response. It is also used to parameterize requests and much better user-perceived performance than a data format that must be entirely received override the default behavior of some connecting elements. For example, cache behavior before rendering can begin. can be modified by control data included in the request or response message. For example, a Web browser that can incrementally render a large HTML document

Depending on the message control data, a given representation may indicate the while it is being received provides significantly better user-perceived performance than current state of the requested resource, the desired state for the requested resource, or the one that waits until the entire document is completely received prior to rendering, even value of some other resource, such as a representation of the input data within a client’s though the network performance is the same. Note that the rendering ability of a query form, or a representation of some error condition for a response. For example, representation can also be impacted by the choice of content. If the dimensions of remote authoring of a resource requires that the author send a representation to the server, dynamically-sized tables and embedded objects must be determined before they can be thus establishing a value for that resource that can be retrieved by later requests. If the rendered, their occurrence within the viewing area of a hypermedia page will increase its value set of a resource at a given time consists of multiple representations, content latency. negotiation may be used to select the best representation for inclusion in a given message. 5.2.2 Connectors The data format of a representation is known as a media type [48]. A representation REST uses various connector types, summarized in Table 5-2, to encapsulate the activities can be included in a message and processed by the recipient according to the control data of accessing resources and transferring resource representations. The connectors present of the message and the nature of the media type. Some media types are intended for an abstract interface for component communication, enhancing simplicity by providing a automated processing, some are intended to be rendered for viewing by a user, and a few clean separation of concerns and hiding the underlying implementation of resources and

91 92 Table 5-2. REST Connectors control data, a resource identifier indicating the target of the request, and an optional

Connector Modern Web Examples representation. The out-parameters consist of response control data, optional resource client libwww, libwww-perl metadata, and an optional representation. From an abstract viewpoint the invocation is server libwww, Apache API, NSAPI

cache browser cache, Akamai cache network synchronous, but both in and out-parameters can be passed as data streams. In other

resolver bind (DNS lookup library) words, processing can be invoked before the value of the parameters is completely known, tunnel SOCKS, SSL after HTTP CONNECT thus avoiding the latency of batch processing large data transfers. communication mechanisms. The generality of the interface also enables substitutability: The primary connector types are client and server. The essential difference between if the users’ only access to the system is via an abstract interface, the implementation can the two is that a client initiates communication by making a request, whereas a server be replaced without impacting the users. Since a connector manages network listens for connections and responds to requests in order to supply access to its services. A communication for a component, information can be shared across multiple interactions in component may include both client and server connectors. order to improve efficiency and responsiveness. A third connector type, the cache connector, can be located on the interface to a client

All REST interactions are stateless. That is, each request contains all of the or server connector in order to save cacheable responses to current interactions so that they information necessary for a connector to understand the request, independent of any can be reused for later requested interactions. A cache may be used by a client to avoid requests that may have preceded it. This restriction accomplishes four functions: 1) it repetition of network communication, or by a server to avoid repeating the process of removes any need for the connectors to retain application state between requests, thus generating a response, with both cases serving to reduce interaction latency. A cache is reducing consumption of physical resources and improving scalability; 2) it allows typically implemented within the address space of the connector that uses it. interactions to be processed in parallel without requiring that the processing mechanism Some cache connectors are shared, meaning that its cached responses may be used in understand the interaction semantics; 3) it allows an intermediary to view and understand answer to a client other than the one for which the response was originally obtained. a request in isolation, which may be necessary when services are dynamically rearranged; Shared caching can be effective at reducing the impact of “flash crowds” on the load of a and, 4) it forces all of the information that might factor into the reusability of a cached popular server, particularly when the caching is arranged hierarchically to cover large response to be present in each request. groups of users, such as those within a company’s intranet, the customers of an Internet

The connector interface is similar to procedural invocation, but with important service provider, or Universities sharing a national network backbone. However, shared differences in the passing of parameters and results. The in-parameters consist of request caching can also lead to errors if the cached response does not match what would have

93 94 been obtained by a new request. REST attempts to balance the desire for transparency in infrastructure is that some REST components may dynamically switch from active cache behavior with the desire for efficient use of the network, rather than assuming that component behavior to that of a tunnel. The primary example is an HTTP proxy that absolute transparency is always required. switches to a tunnel in response to a CONNECT method request [71], thus allowing its

A cache is able to determine the cacheability of a response because the interface is client to directly communicate with a remote server using a different protocol, such as generic rather than specific to each resource. By default, the response to a retrieval request TLS, that doesn’t allow proxies. The tunnel disappears when both ends terminate their is cacheable and the responses to other requests are non-cacheable. If some form of user communication. authentication is part of the request, or if the response indicates that it should not be 5.2.3 Components shared, then the response is only cacheable by a non-shared cache. A component can REST components, summarized in Table 5-3, are typed by their roles in an overall override these defaults by including control data that marks the interaction as cacheable, application action. non-cacheable or cacheable for only a limited time. Table 5-3. REST Components A resolver translates partial or complete resource identifiers into the network address Component Modern Web Examples information needed to establish an inter-component connection. For example, most URI origin server Apache httpd, Microsoft IIS include a DNS hostname as the mechanism for identifying the naming authority for the gateway Squid, CGI, Reverse Proxy proxy CERN Proxy, Netscape Proxy, Gauntlet resource. In order to initiate a request, a Web browser will extract the hostname from the user agent Netscape Navigator, Lynx, MOMspider URI and make use of a DNS resolver to obtain the Internet Protocol address for that authority. Another example is that some identification schemes (e.g., URN [124]) require A user agent uses a client connector to initiate a request and becomes the ultimate an intermediary to translate a permanent identifier to a more transient address in order to recipient of the response. The most common example is a Web browser, which provides access the identified resource. Use of one or more intermediate resolvers can improve the access to information services and renders service responses according to the application longevity of resource references through indirection, though doing so adds to the request needs. latency. An origin server uses a server connector to govern the namespace for a requested tunnel The final form of connector type is a , which simply relays communication resource. It is the definitive source for representations of its resources and must be the across a connection boundary, such as a firewall or lower-level network gateway. The only ultimate recipient of any request that intends to modify the value of its resources. Each reason it is modeled as part of REST and not abstracted away as part of the network

95 96 origin server provides a generic interface to its services as a resource hierarchy. The Proxy Gateway Origin Server resource implementation details are hidden behind the interface. http http $ $ http orb Intermediary components act as both a client and a server in order to forward, with a User Agent DNS b http possible translation, requests and responses. A proxy component is an intermediary $ $ c selected by a client to provide interface encapsulation of other services, data translation, Proxy wais DNS http $ performance enhancement, or security protection. A gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an Client Connector:Client+Cache: $ Server Connector: Server+Cache: $ Figure 5-10. Process View of a REST-based Architecture interface encapsulation of other services, for data translation, performance enhancement, A user agent is portrayed in the midst of three parallel interactions: a, b, and c. The interactions were not satisfied by the user agent’s client connector cache, so each request has been routed to the resource or security enforcement. Note that the difference between a proxy and a gateway is that a origin according to the properties of each resource identifier and the configuration of the client connector. Request (a) has been sent to a local proxy, which in turn accesses a caching gateway found client determines when it will use a proxy. by DNS lookup, which forwards the request on to be satisfied by an origin server whose internal resources are defined by an encapsulated object request broker architecture. Request (b) is sent directly to an origin server, which is able to satisfy the request from its own cache. Request (c) is sent to a proxy that is capable of directly accessing WAIS, an information service that is separate from the Web 5.3 REST Architectural Views architecture, and translating the WAIS response into a format recognized by the generic connector interface. Each component is only aware of the interaction with their own client or server connectors; the overall process topology is an artifact of our view. Now that we have an understanding of the REST architectural elements in isolation, we can use architectural views [105] to describe how the elements work together to form an Figure 5-10 provides a sample of the process view from a REST-based architecture at a architecture. Three types of view—process, connector, and data—are useful for particular instance during the processing of three parallel requests. illuminating the design principles of REST. REST’s client-server separation of concerns simplifies component implementation,

5.3.1 Process View reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system A process view of an architecture is primarily effective at eliciting the interaction constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at relationships among components by revealing the path of data as it flows through the various points in the communication without changing the interfaces between system. Unfortunately, the interaction of a real system usually involves an extensive components, thus allowing them to assist in communication translation or improve number of components, resulting in an overall view that is obscured by the details. performance via large-scale, shared caching. REST enables intermediate processing by

constraining messages to be self-descriptive: interaction is stateless between requests,

97 98 standard methods and media types are used to indicate semantics and exchange connect to a specific proxy component, perhaps one acting as an annotation filter, when information, and responses explicitly indicate cacheability. the identifier indicates that it is a local resource. Likewise, a client can be configured to

Since the components are connected dynamically, their arrangement and function for a reject requests for some subset of identifiers. particular application action has characteristics similar to a pipe-and-filter style. Although REST does not restrict communication to a particular protocol, but it does constrain

REST components communicate via bidirectional streams, the processing of each the interface between components, and hence the scope of interaction and implementation direction is independent and therefore susceptible to stream transducers (filters). The assumptions that might otherwise be made between components. For example, the Web’s generic connector interface allows components to be placed on the stream based on the primary transfer protocol is HTTP, but the architecture also includes seamless access to properties of each request or response. resources that originate on pre-existing network servers, including FTP [107], Gopher [7],

Services may be implemented using a complex hierarchy of intermediaries and and WAIS [36]. Interaction with those services is restricted to the semantics of a REST multiple distributed origin servers. The stateless nature of REST allows each interaction to connector. This constraint sacrifices some of the advantages of other architectures, such as be independent of the others, removing the need for an awareness of the overall the stateful interaction of a relevance feedback protocol like WAIS, in order to retain the component topology, an impossible task for an Internet-scale architecture, and allowing advantages of a single, generic interface for connector semantics. In return, the generic components to act as either destinations or intermediaries, determined dynamically by the interface makes it possible to access a multitude of services through a single proxy. If an target of each request. Connectors need only be aware of each other’s existence during the application needs the additional capabilities of another architecture, it can implement and scope of their communication, though they may cache the existence and capabilities of invoke those capabilities as a separate system running in parallel, similar to how the Web other components for performance reasons. architecture interfaces with “telnet” and “mailto” resources.

5.3.2 Connector View 5.3.3 Data View

A connector view of an architecture concentrates on the mechanics of the communication A data view of an architecture reveals the application state as information flows through between components. For a REST-based architecture, we are particularly interested in the the components. Since REST is specifically targeted at distributed information systems, it constraints that define the generic resource interface. views an application as a cohesive structure of information and control alternatives

Client connectors examine the resource identifier in order to select an appropriate through which a user can perform a desired task. For example, looking-up a word in an communication mechanism for each request. For example, a client may be configured to on-line dictionary is one application, as is touring through a virtual museum, or reviewing

99 100 a set of class notes to study for an exam. Each application defines goals for the underlying The user-perceived performance of a browser application is determined by the latency system, against which the system’s performance can be measured. between steady-states: the period of time between the selection of a hypermedia link on

Component interactions occur in the form of dynamically sized messages. Small or one web page and the point when usable information has been rendered for the next web medium-grain messages are used for control semantics, but the bulk of application work is page. The optimization of browser performance is therefore centered around reducing this accomplished via large-grain messages containing a complete resource representation. communication latency.

The most frequent form of request semantics is that of retrieving a representation of a Since REST-based architectures communicate primarily through the transfer of resource (e.g., the “GET” method in HTTP), which can often be cached for later reuse. representations of resources, latency can be impacted by both the design of the

REST concentrates all of the control state into the representations received in response communication protocols and the design of the representation data formats. The ability to to interactions. The goal is to improve server scalability by eliminating any need for the incrementally render the response data as it is received is determined by the design of the server to maintain an awareness of the client state beyond the current request. An media type and the availability of layout information (visual dimensions of in-line objects) application’s state is therefore defined by its pending requests, the topology of connected within each representation. components (some of which may be filtering buffered data), the active requests on those An interesting observation is that the most efficient network request is one that doesn’t connectors, the data flow of representations in response to those requests, and the use the network. In other words, the ability to reuse a cached response results in a processing of those representations as they are received by the user agent. considerable improvement in application performance. Although use of a cache adds some

An application reaches a steady-state whenever it has no outstanding requests; i.e., it latency to each individual request due to lookup overhead, the average request latency is has no pending requests and all of the responses to its current set of requests have been significantly reduced when even a small percentage of requests result in usable cache hits. completely received or received to the point where they can be treated as a representation The next control state of an application resides in the representation of the first data stream. For a browser application, this state corresponds to a “web page,” including requested resource, so obtaining that first representation is a priority. REST interaction is the primary representation and ancillary representations, such as in-line images, therefore improved by protocols that “respond first and think later.” In other words, a embedded applets, and style sheets. The significance of application steady-states is seen in protocol that requires multiple interactions per user action, in order to do things like their impact on both user-perceived performance and the burstiness of network request negotiate feature capabilities prior to sending a content response, will be perceptively traffic. slower than a protocol that sends whatever is most likely to be optimal first and then

provides a list of alternatives for the client to retrieve if the first response is unsatisfactory.

101 102 The application state is controlled and stored by the user agent and can be composed its standard interfaces and protocols, not how those interfaces and protocols are of representations from multiple servers. In addition to freeing the server from the implemented in a given piece of software. scalability problems of storing state, this allows the user to directly manipulate the state The REST style draws from many preexisting distributed process paradigms [6, 50],

(e.g., a Web browser’s history), anticipate changes to that state (e.g., link maps and communication protocols, and software fields. REST component interactions are prefetching of representations), and jump from one application to another (e.g., structured in a layered client-server style, but the added constraints of the generic resource bookmarks and URI-entry dialogs). interface create the opportunity for substitutability and inspection by intermediaries.

The model application is therefore an engine that moves from one state to the next by Requests and responses have the appearance of a remote invocation style, but REST examining and choosing from among the alternative state transitions in the current set of messages are targeted at a conceptual resource rather than an implementation identifier. representations. Not surprisingly, this exactly matches the user interface of a hypermedia Several attempts have been made to model the Web architecture as a form of browser. However, the style does not assume that all applications are browsers. In fact, the distributed file system (e.g., WebNFS) or as a distributed object system [83]. However, application details are hidden from the server by the generic connector interface, and thus they exclude various Web resource types or implementation strategies as being “not a user agent could equally be an automated robot performing information retrieval for an interesting,” when in fact their presence invalidates the assumptions that underlie such indexing service, a personal agent looking for data that matches certain criteria, or a models. REST works well because it does not limit the implementation of resources to maintenance spider busy patrolling the information for broken references or modified certain predefined models, allowing each application to choose an implementation that content [39]. best matches its own needs and enabling the replacement of implementations without

impacting the user. 5.4 Related Work The interaction method of sending representations of resources to consuming Bass, et al. [9] devote a chapter on architecture for the World Wide Web, but their components has some parallels with event-based integration (EBI) styles. The key description only encompasses the implementation architecture within the CERN/W3C difference is that EBI styles are push-based. The component containing the state developed libwww (client and server libraries) and Jigsaw software. Although those (equivalent to an origin server in REST) issues an event whenever the state changes, implementations reflect many of the design constraints of REST, having been developed whether or not any component is actually interested in or listening for such an event. In the by people familiar with the Web’s architectural design and rationale, the real WWW REST style, consuming components usually pull representations. Although this is less architecture is independent of any single implementation. The modern Web is defined by

103 104 efficient when viewed as a single client wishing to monitor a single resource, the scale of deployment of the modern Web architecture. This work included authoring the current the Web makes an unregulated push model infeasible. Internet standards-track specifications of the Hypertext Transfer Protocol (HTTP/1.1) and

The principled use of the REST style in the Web, with its clear notion of components, Uniform Resource Identifiers (URI), and implementing the architecture through the connectors, and representations, relates closely to the C2 architectural style [128]. The C2 libwww-perl client protocol library and Apache HTTP server. style supports the development of distributed, dynamic applications by focusing on structured use of connectors to obtain substrate independence. C2 applications rely on asynchronous notification of state changes and request messages. As with other event- based schemes, C2 is nominally push-based, though a C2 architecture could operate in

REST’s pull style by only emitting a notification upon receipt of a request. However, the

C2 style lacks the intermediary-friendly constraints of REST, such as the generic resource interface, guaranteed stateless interactions, and intrinsic support for caching.

5.5 Summary

This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. 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. I described 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.

The next chapter presents an evaluation of the REST architecture through the experience and lessons learned from applying REST to the design, specification, and

105 106 CHAPTER 6 MOMspider [39]. At the time, the Web’s architecture was described by a set of informal Experience and Evaluation hypertext notes [14], two early introductory papers [12, 13], draft hypertext specifications representing proposed features for the Web (some of which had already been

implemented), and the archive of the public www-talk mailing list that was used for Since 1994, the REST architectural style has been used to guide the design and informal discussion among the participants in the WWW project worldwide. Each of the development of the architecture for the modern Web. This chapter describes the specifications were significantly out of date when compared with Web implementations, experience and lessons learned from applying REST while authoring the Internet mostly due to the rapid evolution of the Web after the introduction of the Mosaic graphical standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers browser [NCSA]. Several experimental extensions had been added to HTTP to allow for (URI), the two specifications that define the generic interface used by all component proxies, but for the most part the protocol assumed a direct connection between the user interactions on the Web, as well as from the deployment of these technologies in the form agent and either an HTTP origin server or a gateway to legacy systems. There was no of the libwww-perl client library, the Apache HTTP Server Project, and other awareness within the architecture of caching, proxies, or spiders, even though implementations of the protocol standards. implementations were readily available and running amok. Many other extensions were

6.1 Standardizing the Web being proposed for inclusion in the next versions of the protocols.

As described in Chapter 4, the motivation for developing REST was to create an At the same time, there was growing pressure within the industry to standardize on architectural model for how the Web should work, such that it could serve as the guiding some version, or versions, of the Web interface protocols. The W3C was formed by framework for the Web protocol standards. REST has been applied to describe the desired Berners-Lee [20] to act as a think-tank for Web architecture and to supply the authoring

Web architecture, help identify existing problems, compare alternative solutions, and resources needed to write the Web standards and reference implementations, but the ensure that protocol extensions would not violate the core constraints that make the Web standardization itself was governed by the Internet Engineering Taskforce [www.ietf.org] successful. This work was done as part of the Internet Engineering Taskforce (IETF) and and its working groups on URI, HTTP, and HTML. Due to my experience developing

World Wide Web Consortium (W3C) efforts to define the architectural standards for the Web software, I was first chosen to author the specification for Relative URL [40], later

Web: HTTP, URI, and HTML. teamed with Henrik Frystyk Nielsen to author the HTTP/1.0 specification [19], became

My involvement in the Web standards process began in late 1993, while developing the primary architect of HTTP/1.1 [42], and finally authored the revision of the URL the libwww-perl protocol library that served as the client connector interface for specifications to form the standard on URI generic syntax [21].

107 108 The first edition of REST was developed between October 1994 and August 1995, Universal Document Identifiers, Universal Resource Identifiers [15], and finally the primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 combination of Uniform Resource Locators (URL) [17] and Names (URN) [124]. Aside specification and the initial HTTP/1.1 proposal. It was iteratively improved over the next from its name, the URI syntax has remained relatively unchanged since 1992. However, five years and applied to various revisions and extensions of the Web protocol standards. the specification of Web addresses also defines the scope and semantics of what we mean

REST was originally referred to as the “HTTP object model,” but that name would often by resource, which has changed since the early Web architecture. REST was used to lead to misinterpretation of it as the implementation model of an HTTP server. The name define the term resource for the URI standard [21], as well as the overall semantics of the

“Representational State Transfer” is intended to evoke an image of how a well-designed generic interface for manipulating resources via their representations.

Web application behaves: a network of web pages (a virtual state-machine), where the 6.2.1 Redefinition of Resource user progresses through the application by selecting links (state transitions), resulting in The early Web architecture defined URI as document identifiers. Authors were instructed the next page (representing the next state of the application) being transferred to the user to define identifiers in terms of a document’s location on the network. Web protocols and rendered for their use. could then be used to retrieve that document. However, this definition proved to be REST is not intended to capture all possible uses of the Web protocol standards. There unsatisfactory for a number of reasons. First, it suggests that the author is identifying the are applications of HTTP and URI that do not match the application model of a distributed content transferred, which would imply that the identifier should change whenever the hypermedia system. The important point, however, is that REST does capture all of those content changes. Second, there exist many addresses that corresponded to a service rather aspects of a distributed hypermedia system that are considered central to the behavioral than a document — authors may be intending to direct readers to that service, rather than and performance requirements of the Web, such that optimizing behavior within the to any specific result from a prior access of that service. Finally, there exist addresses that model will result in optimum behavior within the deployed Web architecture. In other do not correspond to a document at some periods of time, such as when the document does words, REST is optimized for the common case so that the constraints it applies to the not yet exist or when the address is being used solely for naming, rather than locating, Web architecture will also be optimized for the common case. information.

6.2 REST Applied to URI The definition of resource in REST is based on a simple premise: identifiers should change as infrequently as possible. Because the Web uses embedded identifiers rather than Uniform Resource Identifiers (URI) are both the simplest element of the Web architecture link servers, authors need an identifier that closely matches the semantics they intend by a and the most important. URI have been known by many names: WWW addresses,

109 110 hypermedia reference, allowing the reference to remain static even though the result of Information hiding is one of the key software engineering principles that motivates the accessing that reference may change over time. REST accomplishes this by defining a uniform interface of REST. Because a client is restricted to the manipulation of resource to be the semantics of what the author intends to identify, rather than the value representations rather than directly accessing the implementation of a resource, the corresponding to those semantics at the time the reference is created. It is then left to the implementation can be constructed in whatever form is desired by the naming authority author to ensure that the identifier chosen for a reference does indeed identify the intended without impacting the clients that may use its representations. In addition, if multiple semantics. representations of the resource exist at the time it is accessed, a content selection

algorithm can be used to dynamically select a representation that best fits the capabilities 6.2.2 Manipulating Shadows of that client. The disadvantage, of course, is that remote authoring of a resource is not as Defining resource such that a URI identifies a concept rather than a document leaves us straightforward as remote authoring of a file. with another question: how does a user access, manipulate, or transfer a concept such that they can get something useful when a hypertext link is selected? REST answers that 6.2.3 Remote Authoring question by defining the things that are manipulated to be representations of the identified The challenge of remote authoring via the Web’s uniform interface is due to the separation resource, rather than the resource itself. An origin server maintains a mapping from between the representation that can be retrieved by a client and the mechanism that might resource identifiers to the set of representations corresponding to each resource. A be used on the server to store, generate, or retrieve the content of that representation. An resource is therefore manipulated by transferring representations through the generic individual server may map some part of its namespace to a filesystem, which in turn maps interface defined by the resource identifier. to the equivalent of an inode that can be mapped into a disk location, but those underlying

REST’s definition of resource derives from the central requirement of the Web: mechanisms provide a means of associating a resource to a set of representations rather independent authoring of interconnected hypertext across multiple trust domains. Forcing than identifying the resource itself. Many different resources could map to the same the interface definitions to match the interface requirements causes the protocols to seem representation, while other resources may have no representation mapped at all. vague, but that is only because the interface being manipulated is only an interface and not In order to author an existing resource, the author must first obtain the specific source an implementation. The protocols are specific about the intent of an application action, but resource URI: the set of URI that bind to the handler's underlying representation for the the mechanism behind the interface must decide how that intention affects the underlying target resource. A resource does not always map to a singular file, but all resources that implementation of the resource mapping to representations. are not static are derived from some other resources, and by following the derivation tree

111 112 an author can eventually find all of the source resources that must be edited in order to 6.2.4 Binding Semantics to URI modify the representation of a resource. These same principles apply to any form of As mentioned above, a resource can have many identifiers. In other words, there may exist derived representation, whether it be from content negotiation, scripts, servlets, managed two or more different URI that have equivalent semantics when used to access a server. It configurations, versioning, etc. is also possible to have two URI that result in the same mechanism being used upon access

The resource is not the storage object. The resource is not a mechanism that the server to the server, and yet those URI identify two different resources because they don’t mean uses to handle the storage object. The resource is a conceptual mapping — the server the same thing. receives the identifier (which identifies the mapping) and applies it to its current mapping Semantics are a by-product of the act of assigning resource identifiers and populating implementation (usually a combination of collection-specific deep tree traversal and/or those resources with representations. At no time whatsoever do the server or client hash tables) to find the currently responsible handler implementation and the handler software need to know or understand the meaning of a URI — they merely act as a conduit implementation then selects the appropriate action+response based on the request content. through which the creator of a resource (a human naming authority) can associate

All of these implementation-specific issues are hidden behind the Web interface; their representations with the semantics identified by the URI. In other words, there are no nature cannot be assumed by a client that only has access through the Web interface. resources on the server; just mechanisms that supply answers across an abstract interface

For example, consider what happens when a Web site grows in user base and decides defined by resources. It may seem odd, but this is the essence of what makes the Web to replace its old Brand X server, based on an XOS platform, with a new Apache server work across so many different implementations. running on FreeBSD. The disk storage hardware is replaced. The operating system is It is the nature of every engineer to define things in terms of the characteristics of the replaced. The HTTP server is replaced. Perhaps even the method of generating responses components that will be used to compose the finished product. The Web doesn't work that for all of the content is replaced. However, what doesn't need to change is the Web way. The Web architecture consists of constraints on the communication model between interface: if designed correctly, the namespace on the new server can mirror that of the components, based on the role of each component during an application action. This old, meaning that from the client's perspective, which only knows about resources and not prevents the components from assuming anything beyond the resource abstraction, thus about how they are implemented, nothing has changed aside from the improved hiding the actual mechanisms on either side of the abstract interface. robustness of the site.

113 114 6.2.5 REST Mismatches in URI system, and because both data and metadata are included within, and significant to, the

Like most real-world systems, not all components of the deployed Web architecture obey semantics of a representation. Web server content can be replicated at remote sites, but every constraint present in its architectural design. REST has been used both as a means to only by replicating the entire server mechanism and configuration, or by selectively define architectural improvements and to identify architectural mismatches. Mismatches replicating only those resources with representations known to be static (e.g., cache occur when, due to ignorance or oversight, a software implementation is deployed that networks contract with Web sites to replicate specific resource representations to the violates the architectural constraints. While mismatches cannot be avoided in general, it is “edges” of the overall Internet in order to reduce latency and distribute load away from the possible to identify them before they become standardized. origin server).

Although the URI design matches REST’s architectural notion of identifiers, syntax 6.3 REST Applied to HTTP alone is insufficient to force naming authorities to define their own URI according to the The Hypertext Transfer Protocol (HTTP) has a special role in the Web architecture as both resource model. One form of abuse is to include information that identifies the current the primary application-level protocol for communication between Web components and user within all of the URI referenced by a hypermedia response representation. Such the only protocol designed specifically for the transfer of resource representations. Unlike embedded user-ids can be used to maintain session state on the server, track user behavior URI, there were a large number of changes needed in order for HTTP to support the by logging their actions, or carry user preferences across multiple actions (e.g., Hyper-G’s modern Web architecture. The developers of HTTP implementations have been gateways [84]). However, by violating REST’s constraints, these systems also cause conservative in their adoption of proposed enhancements, and thus extensions needed to shared caching to become ineffective, reduce server scalability, and result in undesirable be proven and subjected to standards review before they could be deployed. REST was effects when a user shares those references with others. used to identify problems with the existing HTTP implementations, specify an Another conflict with the resource interface of REST occurs when software attempts interoperable subset of that protocol as HTTP/1.0 [19], analyze proposed extensions for to treat the Web as a distributed file system. Since file systems expose the implementation HTTP/1.1 [42], and provide motivating rationale for deploying HTTP/1.1. of their information, tools exist to “mirror” that information across to multiple sites as a The key problem areas in HTTP that were identified by REST included planning for means of load balancing and redistributing the content closer to users. However, they can the deployment of new protocol versions, separating message parsing from HTTP do so only because files have a fixed set of semantics (a named sequence of bytes) that can semantics and the underlying transport layer (TCP), distinguishing between authoritative be duplicated easily. In contrast, attempts to mirror the content of a Web server as files and non-authoritative responses, fine-grained control of caching, and various aspects of will fail because the resource interface does not always match the semantics of a file

115 116 the protocol that failed to be self-descriptive. REST has also been used to model the negotiation on the HTTP scale. Each connection on a request/response chain can operate performance of Web applications based on HTTP and anticipate the impact of such at its best protocol level in spite of the limitations of some clients or servers that are parts extensions as persistent connections and content negotiation. Finally, REST has been used of the chain. to limit the scope of standardized HTTP extensions to those that fit within the architectural The intention of the protocol is that the server should always respond with the highest model, rather than allowing the applications that misuse HTTP to equally influence the minor version of the protocol it understands within the same major version of the client’s standard. request message. The restriction is that the server cannot use those optional features of the

higher-level protocol which are forbidden to be sent to such an older-version client. There 6.3.1 Extensibility are no required features of a protocol that cannot be used with all other minor versions One of the major goals of REST is to support the gradual and fragmented deployment of within that major version, since that would be an incompatible change and thus require a changes within an already deployed architecture. HTTP was modified to support that goal change in the major version. The only features of HTTP that can depend on a minor through the introduction of versioning requirements and rules for extending each of the version number change are those that are interpreted by immediate neighbors in the protocol’s syntax elements. communication, because HTTP does not require that the entire request/response chain of

6.3.1.1 Protocol Versioning intermediary components speak the same version.

HTTP is a family of protocols, distinguished by major and minor version numbers, that These rules exist to assist in the deployment of multiple protocol revisions and to share the name primarily because they correspond to the protocol expected when prevent the HTTP architects from forgetting that deployment of the protocol is an communicating directly with a service based on the “http” URL namespace. A connector important aspect of its design. They do so by making it easy to differentiate between must obey the constraints placed on the HTTP-version protocol element included in each compatible changes to the protocol and incompatible changes. Compatible changes are message [90]. easy to deploy and communication of the differences can be achieved within the protocol

The HTTP-version of a message represents the protocol capabilities of the sender and stream. Incompatible changes are difficult to deploy because they require some the gross-compatibility (major version number) of the message being sent. This allows a determination of acceptance of the protocol before the protocol stream can commence. client to use a reduced (HTTP/1.0) subset of features in making a normal HTTP/1.1 6.3.1.2 Extensible Protocol Elements request, while at the same time indicating to the recipient that it is capable of supporting HTTP includes a number of separate namespaces, each of which has differing constraints, full HTTP/1.1 communication. In other words, it provides a tentative form of protocol but all of which share the requirement of being extensible without bound. Some of the

117 118 namespaces are governed by separate Internet standards and shared by multiple protocols Likewise, HTTP needed a general rule for interpreting new response status codes,

(e.g., URI schemes [21], media types [48], MIME header field names [47], charset values, such that new responses could be deployed without significantly harming older clients. language tags), while others are governed by HTTP, including the namespaces for method We therefore expanded upon the rule that each status code belonged to a class signified by names, response status codes, non-MIME header field names, and values within standard the first digit of its three-digit decimal number: 100-199 indicating that the message

HTTP header fields. Since early HTTP did not define a consistent set of rules for how contains a provisional information response, 200-299 indicating that the request changes within these namespaces could be deployed, this was one of the first problems succeeded, 300-399 indicating that the request needs to be redirected to another resource, tackled by the specification effort. 400-499 indicating that the client made an error that should not be repeated, and 500-599

HTTP request semantics are signified by the request method name. Method extension indicating that the server encountered an error, but that the client may get a better response is allowed whenever a standardizable set of semantics can be shared between client, later (or via some other server). If a recipient does not understand the specific semantics of server, and any intermediaries that may be between them. Unfortunately, early HTTP the status code in a given message, then they must treat it in the same way as the x00 code extensions, specifically the HEAD method, made the parsing of an HTTP response within its class. Like the rule for method names, this extensibility rule places a message dependent on knowing the semantics of the request method. This led to a requirement on the current architecture such that it anticipates future change. Changes can deployment contradiction: if a recipient needs to know the semantics of a method before it therefore be deployed onto an existing architecture with less fear of adverse component can be safely forwarded by an intermediary, then all intermediaries must be updated reactions. before a new method can be deployed. 6.3.1.3 Upgrade This deployment problem was fixed by separating the rules for parsing and forwarding The addition of the Upgrade header field in HTTP/1.1 reduces the difficulty of deploying HTTP messages from the semantics associated with new HTTP protocol elements. For incompatible changes by allowing the client to advertise its willingness for a better example, HEAD is the only method for which the Content-Length header field has a protocol while communicating in an older protocol stream. Upgrade was specifically meaning other than signifying the message body length, and no new method can change added to support the selective replacement of HTTP/1.x with other, future protocols that the message length calculation. GET and HEAD are also the only methods for which might be more efficient for some tasks. Thus, HTTP not only supports internal conditional request header fields have the semantics of a cache refresh, whereas for all extensibility, but also complete replacement of itself during an active connection. If the other methods they have the meaning of a precondition. server supports the improved protocol and desires to switch, it simply responds with a 101

status and continues on as if the request were received in that upgraded protocol.

119 120 6.3.2 Self-descriptive Messages 6.3.2.2 Layered Encodings

REST constrains messages between components to be self-descriptive in order to support HTTP inherited its syntax for describing representation metadata from the Multipurpose intermediate processing of interactions. However, there were aspects of early HTTP that Internet Mail Extensions (MIME) [47]. MIME does not define layered media types, failed to be self-descriptive, including the lack of host identification within requests, preferring instead to only include the label of the outermost media type within the failure to syntactically distinguish between message control data and representation Content-Type field value. However, this prevents a recipient from determining the nature metadata, failure to differentiate between control data intended only for the immediate of an encoded message without decoding the layers. An early HTTP extension worked connection peer versus metadata intended for all recipients, lack of support for mandatory around this failing by listing the outer encodings separately within the Content-Encoding extensions, and the need for metadata to describe representations with layered encodings. field and placing the label for the innermost media type in the Content-Type. That was a

6.3.2.1 Host poor design decision, since it changed the semantics of Content-Type without changing its field name, resulting in confusion whenever older user agents encountered the extension. One of the worst mistakes in the early HTTP design was the decision not to send the A better solution would have been to continue treating Content-Type as the outermost complete URI that is the target of a request message, but rather send only those portions media type, and use a new field to describe the nested types within that type. that were not used in setting up the connection. The assumption was that a server would Unfortunately, the first extension was deployed before its faults were identified. know its own naming authority based on the IP address and TCP port of the connection. REST did identify the need for another layer of encodings: those placed on a message However, this failed to anticipate that multiple naming authorities might exist on a single by a connector in order to improve its transferability over the network. This new layer, server, which became a critical problem as the Web grew at an exponential rate and new called a transfer-encoding in reference to a similar concept in MIME, allows messages to domain names (the basis for naming authority within the http URL namespace) far be encoded for transfer without implying that the representation is encoded by nature. exceeded the availability of new IP addresses. Transfer encodings can be added or removed by transfer agents, for whatever reason, The solution defined and deployed for both HTTP/1.0 and HTTP/1.1 was to include without changing the semantics of the representation. the target URL’s host information within a Host header field of the request message.

Deployment of this feature was considered so important that the HTTP/1.1 specification 6.3.2.3 Semantic Independence requires servers to reject any HTTP/1.1 request that doesn’t include a Host field. As a As described above, HTTP message parsing has been separated from its semantics. result, there now exist many large ISP servers that run tens of thousands of name-based Message parsing, including finding and globbing together the header fields, occurs virtual host websites on a single IP address. entirely separate from the process of parsing the header field contents. In this way,

121 122 intermediaries can quickly process and forward HTTP messages, and extensions can be implementation. The result is often a lowest-common-denominator protocol that cannot be deployed without breaking existing parsers. extended much beyond the envisioning of its original creator.

6.3.2.4 Transport Independence There is no limit in the HTTP protocol on the length of URI, the length of header fields, the length of an representation, or the length of any field value that consists of a list Early HTTP, including most implementations of HTTP/1.0, used the underlying transport of items. Although older Web clients have a well-known problem with URI that consist of protocol as the means for signaling the end of a response message. A server would more than 255 characters, it is sufficient to note that problem in the HTTP specification indicate the end of a response message body by closing the TCP connection. rather than require that all servers be so limited. The reason that this does not make for a Unfortunately, this created a significant failure condition in the protocol: a client had no protocol maximum is that applications within a controlled context (such as an intranet) means for distinguishing between a completed response and one that was truncated by can avoid those limits by replacing the older components. some erroneous network failure. To solve this, the Content-Length header fields was Although we did not need to invent artificial limitations, HTTP/1.1 did need to define redefined within HTTP/1.0 to indicate the message body length in bytes, whenever the an appropriate set of response status codes for indicating when a given protocol element is length is known in advance, and the “chunked” transfer encoding was introduced to too long for a server to process. Such response codes were added for the conditions of HTTP/1.1. Request-URI too long, header field too long, and body too long. Unfortunately, there is no The chunked encoding allows a representation whose size is unknown at the beginning way for a client to indicate to a server that it may have resource limits, which leads to of its generation (when the header fields are sent) to have its boundaries delineated by a problems when resource-constrained devices, such as PDAs, attempt to use HTTP without series of chunks that can be individually sized before being sent. It also allows metadata to a device-specific intermediary adjusting the communication. be sent at the end of the message as trailers, enabling the creation of optional metadata at the origin while the message is being generated, without adding to response latency. 6.3.2.6 Cache Control

6.3.2.5 Size Limits Because REST tries to balance the need for efficient, low-latency behavior with the desire for semantically transparent cache behavior, it is critical that HTTP allow the application A frequent barrier to the flexibility of application-layer protocols is the tendency to over- to determine the caching requirements rather than hard-code it into the protocol itself. The specify size limits on protocol parameters. Although there always exist some practical most important thing for the protocol to do is to fully and accurately describe the data limits within implementations of the protocol (e.g., available memory), specifying those being transferred, so that no application is fooled into thinking it has one thing when it limits within the protocol restricts all applications to the same limits, regardless of their

123 124 actually has something else. HTTP/1.1 does this through the addition of the Cache- might normally send once it knows they are having an effect on the response received.

Control, Age, Etag, and Vary header fields. HTTP/1.1 introduced the Vary header field for this purpose. Vary simply lists the request

6.3.2.7 Content Negotiation header field dimensions under which the response may vary. In preemptive negotiation, the user agent tells the server what it is capable of All resources map a request (consisting of method, identifier, request-header fields, and accepting. The server is then supposed to select the representation that best matches what sometimes a representation) to a response (consisting of a status code, response-header the user agent claims to be its capabilities. However, this is a non-tractable problem fields, and sometimes a representation). When an HTTP request maps to multiple because it requires not only information on what the UA will accept, but also how well it representations on the server, the server may engage in content negotiation with the client accepts each feature and to what purpose the user intends to put the representation. For in order to determine which one best meets the client’s needs. This is really more of a example, a user that wants to view an image on screen might prefer a simple bitmap “content selection” process than negotiation. representation, but the same user with the same browser may prefer a PostScript Although there were several deployed implementations of content negotiation, it was representation if they intend to send it to a printer instead. It also depends on the user not included in the specification of HTTP/1.0 because there was no interoperable subset of correctly configuring their browser according to their own personal content preferences. implementations at the time it was published. This was partly due to a poor In short, a server is rarely able to make effective use of preemptive negotiation, but it was implementation within NCSA Mosaic, which would send 1KB of preference information the only form of automated content selection defined by early HTTP. in the header fields on every request, regardless of the negotiability of the resource [125]. HTTP/1.1 added the notion of reactive (agent-driven) negotiation. In this case, when a Since far less than 0.01% of all URI are negotiable in content, the result was substantially user agent requests a negotiated resource, the server responds with a list of the available increased request latency for very little gain, which led to later browsers disregarding the representations. The user agent can then choose which one is best according to its own negotiation features of HTTP/1.0. capabilities and purpose. The information about the available representations may be Preemptive (server-driven) negotiation occurs when the server varies the response supplied via a separate representation (e.g., a 300 response), inside the response data (e.g., representation for a particular request method*identifier*status-code combination conditional HTML), or as a supplement to the “most likely” response. The latter works according to the value of the request header fields, or something external to the normal best for the Web because an additional interaction only becomes necessary if the user request parameters above. The client needs to be notified when this occurs, so that a cache agent decides one of the other variants would be better. Reactive negotiation is simply an can know when it is semantically transparent to use a particular cached response for a future request, and also so that a user agent can supply more detailed preferences than it

125 126 automated reflection of the normal browser model, which means it can take full advantage overhead of per-interaction set-up costs and the nature of TCP’s slow-start congestion of all the performance benefits of REST. control algorithm [63, 125]. As a result, several extensions were proposed to combine

Both preemptive and reactive negotiation suffer from the difficulty of communicating multiple requests and responses within a single connection. the actual characteristics of the representation dimensions (e.g., how to say that a browser The first proposal was to define a new set of methods for encapsulating multiple supports HTML tables but not the INSERT element). However, reactive negotiation has requests within a single message (MGET, MHEAD, etc.) and returning the response as a the distinct advantages of not having to send preferences on every request, having more MIME multipart. This was rejected because it violated several of the REST constraints. context information with which to make a decision when faced with alternatives, and not First, the client would need to know all of the requests it wanted to package before the first interfering with caches. request could be written to the network, since a request body must be length-delimited by

A third form of negotiation, transparent negotiation [64], is a license for an a content-length field set in the initial request header fields. Second, intermediaries would intermediary cache to act as an agent, on behalf of other agents, for selecting a better have to extract each of the messages to determine which ones it could satisfy locally. representation and initiating requests to retrieve that representation. The request may be Finally, it effectively doubles the number of request methods and complicates resolved internally by another cache hit, and thus it is possible that no additional network mechanisms for selectively denying access to certain methods. request will be made. In so doing, however, they are performing server-driven negotiation, Instead, we adopted a form of persistent connections, which uses length-delimited and must therefore add the appropriate Vary information so that other outbound caches messages in order to send multiple HTTP messages on a single connection [100]. For won’t be confused. HTTP/1.0, this was done using the “keep-alive” directive within the Connection header

field. Unfortunately, that did not work in general because the header field could be 6.3.3 Performance forwarded by intermediaries to other intermediaries that do not understand keep-alive, HTTP/1.1 focused on improving the semantics of communication between components, resulting in a dead-lock condition. HTTP/1.1 eventually settled on making persistent but there were also some improvements to user-perceived performance, albeit limited by connections the default, thus signaling their presence via the HTTP-version value, and the requirement of syntax compatibility with HTTP/1.0. only using the connection-directive “close” to reverse the default.

6.3.3.1 Persistent Connections It is important to note that persistent connections only became possible after HTTP

Although early HTTP’s single request/response per connection behavior made for simple messages were redefined to be self-descriptive and independent of the underlying implementations, it resulted in inefficient use of the underlying TCP transport due to the transport protocol.

127 128 6.3.3.2 Write-through Caching HTTP/1.1 did add a mechanism to control cache behavior such that the desire for an

HTTP does not support write-back caching. An HTTP cache cannot assume that what gets authoritative response can be indicated. The ’no-cache’ directive on a request message written through it is the same as what would be retrievable from a subsequent request for requires any cache to forward the request toward the origin server even if it has a cached that resource, and thus it cannot cache a PUT request body and reuse it for a later GET copy of what is being requested. This allows a client to refresh a cached copy which is response. There are two reasons for this rule: 1) metadata might be generated behind-the- known to be corrupted or stale. However, using this field on a regular basis interferes with scenes, and 2) access control on later GET requests cannot be determined from the PUT the performance benefits of caching. A more general solution would be to require that request. However, since write actions using the Web are extremely rare, the lack of write- responses be marked as non-authoritative whenever an action does not result in contacting back caching does not have a significant impact on performance. the origin server. A Warning response header field was defined in HTTP/1.1 for this

purpose (and others), but it has not been widely implemented in practice. 6.3.4 REST Mismatches in HTTP 6.3.4.2 Cookies There are several architectural mismatches present within HTTP, some due to 3rd-party An example of where an inappropriate extension has been made to the protocol to support extensions that were deployed external to the standards process and others due to the features that contradict the desired properties of the generic interface is the introduction of necessity of remaining compatible with deployed HTTP/1.0 components. site-wide state information in the form of HTTP cookies [73]. Cookie interaction fails to 6.3.4.1 Differentiating Non-authoritative Responses match REST’s model of application state, often resulting in confusion for the typical One weakness that still exists in HTTP is that there is no consistent mechanism for browser application. differentiating between authoritative responses, which are generated by the origin server An HTTP cookie is opaque data that can be assigned by the origin server to a user in response to the current request, and non-authoritative responses that are obtained from agent by including it within a Set-Cookie response header field, with the intention being an intermediary or cache without accessing the origin server. The distinction can be that the user agent should include the same cookie on all future requests to that server until important for applications that require authoritative responses, such as the safety-critical it is replaced or expires. Such cookies typically contain an array of user-specific information appliances used within the health industry, and for those times when an error configuration choices, or a token to be matched against the server’s database on future response is returned and the client is left wondering whether the error was due to the requests. The problem is that a cookie is defined as being attached to any future requests origin or to some intermediary. Attempts to solve this using additional status codes did not for a given set of resource identifiers, usually encompassing an entire site, rather than succeed, since the authoritative nature is usually orthogonal to the response status. being associated with the particular application state (the set of currently rendered

129 130 representations) on the browser. When the browser’s history functionality (the “Back” such as that proposed in [94]. This is an aspect of the modern Web architecture which does button) is subsequently used to back-up to a view prior to that reflected by the cookie, the not yet match the self-descriptive messaging constraints of the REST architectural style, browser’s application state no longer matches the stored state represented within the primarily because the cost of implementing a mandatory extension framework within the cookie. Therefore, the next request sent to the same server will contain a cookie that existing HTTP syntax exceeds any clear benefits that we might gain from mandatory misrepresents the current application context, leading to confusion on both sides. extensions. However, it is reasonable to expect that mandatory field name extensions will

Cookies also violate REST because they allow data to be passed without sufficiently be supported in the next major revision of HTTP, when the existing constraints on identifying its semantics, thus becoming a concern for both security and privacy. The backwards-compatibility of syntax no longer apply. combination of cookies with the Referer [sic] header field makes it possible to track a user 6.3.4.4 Mixing Metadata as they browse between sites. HTTP is designed to extend the generic connector interface across a network connection. As a result, cookie-based applications on the Web will never be reliable. The same As such, it is intended to match the characteristics of that interface, including the functionality should have been accomplished via anonymous authentication and true delineation of parameters as control data, metadata, and representation. However, two of client-side state. A state mechanism that involves preferences can be more efficiently the most significant limitations of the HTTP/1.x protocol family are that it fails to implemented using judicious use of context-setting URI rather than cookies, where syntactically distinguish between representation metadata and message control judicious means one URI per state rather than an unbounded number of URI due to the information (both transmitted as header fields) and does not allow metadata to be embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping effectively layered for message integrity checks. basket” within a server-side database could be more efficiently implemented by defining REST identified these as limitations in the protocol early in the standardization the semantics of shopping items within the hypermedia data formats, allowing the user process, anticipating that they would lead to problems in the deployment of other features, agent to select and store those items within their own client-side shopping basket, such as persistent connections and digest authentication. Workarounds were developed, complete with a URI to be used for check-out when the client is ready to purchase. including adding the Connection header field to identify per-connection control data that

6.3.4.3 Mandatory Extensions is unsafe to be forwarded by intermediaries, as well as an algorithm for the canonical

HTTP header field names can be extended at will, but only when the information they treatment of header field digests [46]. contain is not required for proper understanding of the message. Mandatory header field extensions require a major protocol revision or a substantial change to method semantics,

131 132 6.3.4.5 MIME Syntax HTTP, even though it will likely continue to use the many standardized protocol elements

HTTP inherited its message syntax from MIME [47] in order to retain commonality with for representation metadata. other Internet protocols and reuse many of the standardized fields for describing media 6.3.5 Matching Responses to Requests types in messages. Unfortunately, MIME and HTTP have very different goals, and the HTTP messages fail to be self-descriptive when it comes to describing which response syntax is only designed for MIME’s goals. belongs with which request. Early HTTP was based on a single request and response per In MIME, a user agent is sending a bunch of information, which is intended to be connection, so there was no perceived need for message control data that would tie the treated as a coherent whole, to an unknown recipient with which they never directly response back to the request that invoked it. Therefore, the ordering of requests interact. MIME assumes that the agent would want to send all that information in one determines the ordering of responses, which means that HTTP relies on the transport message, since sending multiple messages across Internet mail is less efficient. Thus, connection to determine the match. MIME syntax is constructed to package messages within a part or multipart in much the HTTP/1.1, though defined to be independent of the transport protocol, still assumes way postal carriers wrap packages in extra paper. that communication takes place on a synchronous transport. It could easily be extended to In HTTP, packaging different objects within a single message doesn't make any sense work on an asynchronous transport, such as e-mail, through the addition of a request other than for secure encapsulation or packaged archives, since it is more efficient to make identifier. Such an extension would be useful for agents in a broadcast or multicast separate requests for those documents not already cached. Thus, HTTP applications use situation, where responses might be received on a channel different from that of the media types like HTML as containers for references to the “package” — a user agent can request. Also, in a situation where many requests are pending, it would allow the server to then choose what parts of the package to retrieve as separate requests. Although it is choose the order in which responses are transferred, such that smaller or more significant possible that HTTP could use a multipart package in which only the non-URI resources responses are sent first. were included after the first part, there hasn’t been much demand for it.

The problem with MIME syntax is that it assumes the transport is lossy, deliberately 6.4 Technology Transfer corrupting things like line breaks and content lengths. The syntax is therefore verbose and Although REST had its most direct influence over the authoring of Web standards, inefficient for any system not based on a lossy transport, which makes it inappropriate for validation of its use as an architectural design model came through the deployment of the HTTP. Since HTTP/1.1 has the capability to support deployment of incompatible standards in the form of commercial-grade implementations. protocols, retaining the MIME syntax won’t be necessary for the next major version of

133 134 6.4.1 Deployment experience with libwww-perl 6.4.2 Deployment experience with Apache

My involvement in the definition of Web standards began with development of the As the specification effort for HTTP began to take the form of complete specifications, we maintenance robot MOMspider [39] and its associated protocol library, libwww-perl. needed server software that could both effectively demonstrate the proposed standard

Modeled after the original libwww developed by Tim Berners-Lee and the WWW project protocol and serve as a test-bed for worthwhile extensions. At the time, the most popular at CERN, libwww-perl provided a uniform interface for making Web requests and HTTP server (httpd) was the public domain software developed by Rob McCool at the interpreting Web responses for client applications written in the Perl language [134]. It National Center for Supercomputing Applications, University of Illinois, Urbana- was the first Web protocol library to be developed independent of the original CERN Champaign (NCSA). However, development had stalled after Rob left NCSA in mid- project, reflecting a more modern interpretation of the Web interface than was present in 1994, and many webmasters had developed their own extensions and bug fixes that were older code bases. This interface became the basis for designing REST. in need of a common distribution. A group of us created a mailing list for the purpose of

libwww-perl consisted of a single request interface that used Perl’s self-evaluating coordinating our changes as “patches” to the original source. In the process, we created code features to dynamically load the appropriate transport protocol package based on the the Apache HTTP Server Project [89]. scheme of the requested URI. For example, when asked to make a “GET” request on the The Apache project is a collaborative software development effort aimed at creating a

URL , libwww-perl would extract the scheme from the URL robust, commercial-grade, full-featured, open-source software implementation of an

(“http”) and use it to construct a call to wwwhttp’request(), using an interface that was HTTP server. The project is jointly managed by a group of volunteers located around the common to all types of resources (HTTP, FTP, WAIS, local files, etc.). In order to achieve world, using the Internet and the Web to communicate, plan, and develop the server and this generic interface, the library treated all calls in much the same way as an HTTP proxy. its related documentation. These volunteers are known as the Apache Group. More

It provided an interface using Perl data structures that had the same semantics as an HTTP recently, the group formed the nonprofit Apache Software Foundation to act as a legal and request, regardless of the type of resource. financial umbrella organization for supporting continued development of the Apache open

libwww-perl demonstrated the benefits of a generic interface. Within a year of its source projects. initial release, over 600 independent software developers were using the library for their Apache became known for both its robust behavior in response to the varied demands own client tools, ranging from command-line download scripts to full-blown browsers. It of an Internet service and for its rigorous implementation of the HTTP protocol standards. is currently the basis for most Web system administration tools. I served as the “protocol cop” within the Apache Group, writing code for the core HTTP

parsing functions, supporting the efforts of others by explaining the standards, and acting

135 136 as an advocate for the Apache developers’ views of “the right way to implement HTTP” The REST architectural style succeeded in guiding the design and deployment of the within the standards forums. Many of the lessons described in this chapter were learned as modern Web architecture. To date, there have been no significant problems caused by the a result of creating and testing various implementations of HTTP within the Apache introduction of the new standards, even though they have been subject to gradual and project, and subjecting the theories behind the protocol to the Apache Group’s critical fragmented deployment alongside legacy Web applications. Furthermore, the new review. standards have had a positive effect on the robustness of the Web and enabled new

Apache httpd is widely regarded as one of the most successful software projects, and methods for improving user-perceived performance through caching hierarchies and one of the first open-source software products to dominate a market in which there exists content distribution networks. significant commercial competition. The July 2000 Netcraft survey of public Internet 6.5 Architectural Lessons websites found over 20 million sites based on the Apache software, representing over 65% There are a number of general architectural lessons to be learned from the modern Web of all sites surveyed [http://www.netcraft.com/survey/]. Apache was the first major server architecture and the problems identified by REST. to support the HTTP/1.1 protocol and is generally considered the reference implementation against which all client software is tested. The Apache Group received the 6.5.1 Advantages of a Network-based API 1999 ACM Software System Award as recognition of our impact on the standards for the What distinguishes the modern Web from other middleware [22] is the way in which it Web architecture. uses HTTP as a network-based Application Programming Interface (API). This was not

6.4.3 Deployment of URI and HTTP/1.1-compliant Software always the case. The early Web design made use of a library package, CERN libwww, as the single implementation library for all clients and servers. CERN libwww provided a In addition to Apache, many other projects, both commercial and open-source in nature, library-based API for building interoperable Web components. have adopted and deployed software products based on the protocols of the modern Web A library-based API provides a set of code entry points and associated symbol/ architecture. Though it may be only a coincidence, Microsoft Internet Explorer surpassed parameter sets so that a programmer can use someone else’s code to do the dirty work of Netscape Navigator in the Web browser market share shortly after they were the first maintaining the actual interface between like systems, provided that the programmer major browser to implement the HTTP/1.1 client standard. In addition, many of the obeys the architectural and language restrictions that come with that code. The assumption individual HTTP extensions that were defined during the standardization process, such as is that all sides of the communication use the same API, and therefore the internals of the the Host header field, have now reached universal deployment. interface are only important to the API developer and not the application developer.

137 138 The single library approach ended in 1993 because it did not match the social However, it is important to keep in mind that there are various layers involved in any dynamics of the organizations involved in developing the Web. When the team at NCSA architecture, including that of the modern Web. Systems like the Web use one library API increased the pace of Web development with a much larger development team than had (sockets) in order to access several network-based APIs (e.g., HTTP and FTP), but the ever been present at CERN, the libwww source was “forked” (split into separately socket API itself is below the application-layer. Likewise, libwww is an interesting cross- maintained code bases) so that the folks at NCSA would not have to wait for CERN to breed in that it has evolved into a library-based API for accessing a network-based API, catch-up with their improvements. At the same time, independent developers such as and thus provides reusable code without assuming other communicating applications are myself began developing protocol libraries for languages and platforms not yet supported using libwww as well. by the CERN code. The design of the Web had to shift from the development of a This is in contrast to middleware like CORBA [97]. Since CORBA only allows reference protocol library to the development of a network-based API, extending the communication via an ORB, its transfer protocol, IIOP, assumes too much about what the desired semantics of the Web across multiple platforms and implementations. parties are communicating. HTTP request messages include standardized application

A network-based API is an on-the-wire syntax, with defined semantics, for application semantics, whereas IIOP messages do not. The “Request” token in IIOP only supplies interactions. A network-based API does not place any restrictions on the application code directionality so that the ORB can route it according to whether the ORB itself is supposed aside from the need to read/write to the network, but does place restrictions on the set of to reply (e.g., “LocateRequest”) or if it will be interpreted by an object. The semantics are semantics that can be effectively communicated across the interface. On the plus side, expressed by the combination of an object key and operation, which are object-specific performance is only bounded by the protocol design and not by any particular rather than standardized across all objects. implementation of that design. An independent developer can generate the same bits as an IIOP request without using

A library-based API does a lot more for the programmer, but in doing so creates a the same ORB, but the bits themselves are defined by the CORBA API and its Interface great deal more complexity and baggage than is needed by any one system, is less portable Definition Language (IDL). They need a UUID generated by an IDL compiler, a in a heterogeneous network, and always results in genericity being preferred over structured binary content that mirrors that IDL operation's signature, and the definition of performance. As a side-effect, it also leads to lazy development (blaming the API code for the reply data type(s) according to the IDL specification. The semantics are thus not everything) and failure to account for non-cooperative behavior by other parties in the defined by the network interface (IIOP), but by the object's IDL spec. Whether this is a communication. good thing or not depends on the application — for distributed objects it is a necessity, for

the Web it isn't.

139 140 Why is this important? Because it differentiates a system where network as well as by the machines that originate services. The result is an application that allows intermediaries can be effective agents from a system where they can be, at most, routers. for layers of transformation and indirection that are independent of the information origin,

This kind of difference is also seen in the interpretation of a message as a unit or as a which is very useful for an Internet-scale, multi-organization, anarchically scalable stream. HTTP allows the recipient or the sender to decide that on their own. CORBA IDL information system. RPC mechanisms, in contrast, are defined in terms of language APIs, doesn’t even allow streams (yet), but even when it does get extended to support streams, not network-based applications. both sides of the communication will be tied to the same API, rather than being free to use 6.5.3 HTTP is not a Transport Protocol whatever is most appropriate for their type of application. HTTP is not designed to be a transport protocol. It is a transfer protocol in which the

6.5.2 HTTP is not RPC messages reflect the semantics of the Web architecture by performing actions on resources

People often mistakenly refer to HTTP as a remote procedure call (RPC) [23] mechanism through the transfer and manipulation of representations of those resources. It is possible simply because it involves requests and responses. What distinguishes RPC from other to achieve a wide range of functionality using this very simple interface, but following the forms of network-based application communication is the notion of invoking a procedure interface is required in order for HTTP semantics to remain visible to intermediaries. on the remote machine, wherein the protocol identifies the procedure and passes it a fixed That is why HTTP goes through firewalls. Most of the recently proposed extensions to set of parameters, and then waits for the answer to be supplied within a return message HTTP, aside from WebDAV [60], have merely used HTTP as a way to move other using the same interface. Remote method invocation (RMI) is similar, except that the application protocols through a firewall, which is a fundamentally misguided idea. Not procedure is identified as an {object, method} tuple rather than a service procedure. only does it defeat the purpose of having a firewall, but it won’t work for the long term

Brokered RMI adds name service indirection and a few other tricks, but the interface is because firewall vendors will simply have to perform additional protocol filtering. It basically the same. therefore makes no sense to do those extensions on top of HTTP, since the only thing

What distinguishes HTTP from RPC isn’t the syntax. It isn’t even the different HTTP accomplishes in that situation is to add overhead from a legacy syntax. A true characteristics gained from using a stream as a parameter, though that helps to explain application of HTTP maps the protocol user’s actions to something that can be expressed why existing RPC mechanisms were not usable for the Web. What makes HTTP using HTTP semantics, thus creating a network-based API to services which can be significantly different from RPC is that the requests are directed to resources using a understood by agents and intermediaries without any knowledge of the application. generic interface with standard semantics that can be interpreted by intermediaries almost

141 142 6.5.4 Design of Media Types accomplished the same tasks without violating the REST constraints, while leading to a

One aspect of REST that is unusual for an architectural style is the degree to which it better user interface and less interference with caching. influences the definition of data elements within the Web architecture. 6.5.4.2 Incremental Processing

6.5.4.1 Application State in a Network-based System By including latency reduction as an architectural goal, REST can differentiate media

REST defines a model of expected application behavior which supports simple and robust types (the data format of representations) according to their user-perceived performance. applications that are largely immune from the partial failure conditions that beset most Size, structure, and capacity for incremental rendering all have an impact on the latency network-based applications. However, that doesn’t stop application developers from encountered transferring, rendering, and manipulating representation media types, and introducing features which violate the model. The most frequent violations are in regard to thus can significantly impact system performance. the constraints on application state and stateless interaction. HTML [18] is an example of a media type that, for the most part, has good latency

Architectural mismatches due to misplaced application state are not limited to HTTP characteristics. Information within early HTML could be rendered as it was received, cookies. The introduction of “frames” to the Hypertext Markup Language (HTML) caused because all of the rendering information was available early — within the standardized similar confusion. Frames allow a browser window to be partitioned into subwindows, definitions of the small set of mark-up tags that made up HTML. However, there are each with its own navigational state. Link selections within a subwindow are aspects of HTML that were not designed well for latency. Examples include: placement of indistinguishable from normal transitions, but the resulting response representation is embedded metadata within the HEAD of a document, resulting in optional information rendered within the subwindow instead of the full browser application workspace. This is needing to be transferred and processed before the rendering engine can read the parts that fine provided that no link exits the realm of information that is intended for subwindow display something useful to the user [93]; embedded images without rendering size hints, treatment, but when it does occur the user finds themself viewing one application wedged requiring that the first few bytes of the image (the part that contains the layout size) be within the subcontext of another application. received before the rest of the surrounding HTML can be displayed; dynamically sized

For both frames and cookies, the failure was in providing indirect application state that table columns, requiring that the renderer read and determine sizes for the entire table could not be managed or interpreted by the user agent. A design that placed this before it can start displaying the top; and, lazy rules regarding the parsing of malformed information within a primary representation, thereby informing the user agent on how to mark-up syntax, often requiring that the rendering engine parse through an entire file manage the hypermedia workspace for a specified realm of resources, could have before it can determine that one key mark-up character is missing.

143 144 6.5.4.3 Java versus JavaScript servlets, etc.). In order to better understand the reasons for this discrepancy, we need to

REST can also be used to gain insight into why some media types have had greater evaluate Java in terms of its characteristics as a representation media type within REST. adoption within the Web architecture than others, even when the balance of developer JavaScript better fits the deployment model of Web technology. It has a much lower opinion is not in their favor. The case of Java applets versus JavaScript is one example. entry-barrier, both in terms of its overall complexity as a language and the amount of

JavaTM [45] is a popular programming language that was originally developed for initial effort required by a novice programmer to put together their first piece of working applications within television set-top boxes, but first gained notoriety when it was code. JavaScript also has less impact on the visibility of interactions. Independent introduced to the Web as a means for implementing code-on-demand functionality. organizations can read, verify, and copy the JavaScript source code in the same way that

Although the language received a tremendous amount of press support from its owner, they could copy HTML. Java, in contrast, is downloaded as binary packaged archives —

Sun Microsystems, Inc., and rave reviews from software developers seeking an alternative the user is therefore left to trust the security restrictions within the Java execution to the C++ language, it has failed to be widely adopted by application developers for code- environment. Likewise, Java has many more features that are considered questionable to on-demand within the Web. allow within a secure environment, including the ability to send RMI requests back to the

Shortly after Java’s introduction, developers at Netscape Communications origin server. RMI does not support visibility for intermediaries.

Corporation created a separate language for embedded code-on-demand, originally called Perhaps the most important distinction between the two, however, is that JavaScript

LiveScript, but later changed to the name JavaScript for marketing reasons (the two causes less user-perceived latency. JavaScript is usually downloaded as part of the languages have relatively little in common other than that) [44]. Although initially derided primary representation, whereas Java applets require a separate request. Java code, once for being embedded with HTML and yet not compatible with proper HTML syntax, converted to the byte code format, is much larger than typical JavaScript. Finally, whereas

JavaScript usage has steadily increased ever since its introduction. JavaScript can be executed while the rest of the HTML page is downloading, Java requires

The question is: why is JavaScript more successful on the Web than Java? It certainly that the complete package of class files be downloaded and installed before the application isn’t because of its technical quality as a language, since both its syntax and execution can begin. Java, therefore, does not support incremental rendering. environment are considered poor when compared to Java. It also isn’t because of Once the characteristics of the languages are laid out along the same lines as the marketing: Sun far outspent Netscape in that regard, and continues to do so. It isn’t rationale behind REST’s constraints, it becomes much easier to evaluate the technologies because of any intrinsic characteristics of the languages either, since Java has been more in terms of their behavior within the modern Web architecture. successful than JavaScript within all other programming areas (stand-alone applications,

145 146 6.6 Summary CONCLUSIONS

This chapter described the experiences and lessons learned from applying REST while authoring the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Each one of us has, somewhere in his heart, the dream to make a living world, a universe. Those of us who have been trained as architects have this desire Resource Identifiers (URI). These two specifications define the generic interface used by perhaps at the very center of our lives: that one day, somewhere, somehow, we shall build one building which is wonderful, beautiful, breathtaking, a place all component interactions on the Web. In addition, I have described the experiences and where people can walk and dream for centuries. — Christopher Alexander [3] lessons learned from the deployment of these technologies in the form of the libwww-perl client library, the Apache HTTP Server Project, and other implementations of the protocol At the beginning of our efforts within the Internet Engineering Taskforce to define the standards. existing Hypertext Transfer Protocol (HTTP/1.0) [19] and design the extensions for the

new standards of HTTP/1.1 [42] and Uniform Resource Identifiers (URI) [21], I

recognized the need for a model of how the World Wide Web should work. This idealized

model of the interactions within an overall Web application, referred to as the

Representational State Transfer (REST) architectural style, became the foundation for the

modern Web architecture, providing the guiding principles by which flaws in the

preexisting architecture could be identified and extensions validated prior to deployment.

REST is a coordinated set of architectural constraints that attempts to minimize

latency and network communication while at the same time maximizing the independence

and scalability of component implementations. This is achieved by placing constraints on

connector semantics where other styles have focused on component semantics. REST

enables the caching and reuse of interactions, dynamic substitutability of components, and

processing of actions by intermediaries, thereby meeting the needs of an Internet-scale

distributed hypermedia system.

147 148 The following contributions to the field of Information and Computer Science have due to legacy experiments that failed (but must be retained for backwards compatibility) been made as part of this dissertation: and extensions deployed by developers unaware of the architectural style. REST provides

• a framework for understanding software architecture through architectural styles, a model not only for the development and evaluation of new features, but also for the including a consistent set of terminology for describing software architecture; identification and understanding of broken features. • a classification of architectural styles for network-based application software by the architectural properties they would induce when applied to the architecture for The World Wide Web is arguably the world’s largest distributed application. a distributed hypermedia system; Understanding the key architectural principles underlying the Web can help explain its • REST, a novel architectural style for distributed hypermedia systems; and, technical success and may lead to improvements in other distributed applications, • application and evaluation of the REST architectural style in the design and deployment of the architecture for the modern World Wide Web. particularly those that are amenable to the same or similar methods of interaction. REST

The modern Web is one instance of a REST-style architecture. Although Web-based contributes both the rationale behind the modern Web’s software architecture and a applications can include access to other styles of interaction, the central focus of its significant lesson in how software engineering principles can be systematically applied in protocol and performance concerns is distributed hypermedia. REST elaborates only those the design and evaluation of a real software system. portions of the architecture that are considered essential for Internet-scale distributed For network-based applications, system performance is dominated by network hypermedia interaction. Areas for improvement of the Web architecture can be seen where communication. For a distributed hypermedia system, component interactions consist of existing protocols fail to express all of the potential semantics for component interaction, large-grain data transfers rather than computation-intensive tasks. The REST style was and where the details of syntax can be replaced with more efficient forms without developed in response to those needs. Its focus upon the generic connector interface of changing the architecture capabilities. Likewise, proposed extensions can be compared to resources and representations has enabled intermediate processing, caching, and

REST to see if they fit within the architecture; if not, it is more efficient to redirect that substitutability of components, which in turn has allowed Web-based applications to scale functionality to a system running in parallel with a more applicable architectural style. from 100,000 requests/day in 1994 to 600,000,000 requests/day in 1999.

In an ideal world, the implementation of a software system would exactly match its The REST architectural style has been validated through six years of development of design. Some features of the modern Web architecture do correspond exactly to their the HTTP/1.0 [19] and HTTP/1.1 [42] standards, elaboration of the URI [21] and relative design criteria in REST, such as the use of URI [21] as resource identifiers and the use of URL [40] standards, and successful deployment of several dozen independently

Internet media types [48] to identify representation data formats. However, there are also developed, commercial-grade software systems within the modern Web architecture. It some aspects of the modern Web protocols that exist in spite of the architectural design,

149 150 has served as both a model for design guidance and as an acid test for architectural REFERENCES extensions to the Web protocols.

Future work will focus on extending the architectural guidance toward the 1. G. D. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. ACM Transactions on Software Engineering development of a replacement for the HTTP/1.x protocol family, using a more efficient and Methodology, 4(4), Oct. 1995, pp. 319–364. A shorter version also appeared as: Using style to understand descriptions of software architecture. In Proceedings tokenized syntax, but without losing the desirable properties identified by REST. The of the First ACM SIGSOFT Symposium on the Foundations of Software Engineering (SIGSOFT‘93), Los Angeles, CA, Dec. 1993, pp. 9–20. needs of wireless devices, which have many characteristics in common with the principles 2. Adobe Systems Inc. PostScript Language Reference Manual. Addison-Wesley behind REST, will motivate further enhancements for application-level protocol design Publishing Company, Reading, Massachusetts, 1985. and architectures involving active intermediaries. There has also been some interest in 3. C. Alexander. The Timeless Way of Building. Oxford University Press, New York, 1979. extending REST to consider variable request priorities, differentiated quality-of-service, 4. C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and and representations consisting of continuous data streams, such as those generated by S. Angel. A Pattern Language. Oxford University Press, New York, 1977. broadcast audio and video sources. 5. R. Allen and D. Garlan. A formal basis for architectural connection. ACM Transactions on Software Engineering and Methodology, 6(3), July 1997. A shorter version also appeared as: Formalizing architectural connection. In Proceedings of the 16th International Conference on Software Engineering, Sorrento, Italy, May 1994, pp. 71–80. Also as: Beyond Definition/Use: Architectural Interconnection. In Proceedings of the ACM Interface Definition Language Workshop, Portland, Oregon, SIGPLAN Notices, 29(8), Aug. 1994.

6. G. Andrews. Paradigms for process interaction in distributed programs. ACM Computing Surveys, 23(1), Mar. 1991, pp. 49–90.

7. F. Anklesaria, et al. The Internet Gopher protocol (a distributed document search and retrieval protocol). Internet RFC 1436, Mar. 1993.

8. D. J. Barrett, L. A. Clarke, P. L. Tarr, A. E. Wise. A framework for event-based software integration. ACM Transactions on Software Engineering and Methodology, 5(4), Oct. 1996, pp. 378–421.

9. L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison Wesley, Reading, Mass., 1998.

10. D. Batory, L. Coglianese, S. Shafer, and W. Tracz. The ADAGE avionics reference architecture. In Proceedings of AIAA Computing in Aerospace 10, San Antonio, 1995.

151 152 11. T. Berners-Lee, R. Cailliau, and J.-F. Groff. World Wide Web. Flyer distributed at 25. G. Booch. Object-oriented development. IEEE Transactions on Software the 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992. Engineering, 12(2), Feb. 1986, pp. 211–221.

12. T. Berners-Lee, R. Cailliau, J.-F. Groff, and B. Pollermann. World-Wide Web: The 26. C. Brooks, M. S. Mazer, S. Meeks, and J. Miller. Application-specific proxy information universe. Electronic Networking: Research, Applications and Policy, servers as HTTP stream transducers. In Proceedings of the Fourth International 2(1), Meckler Publishing, Westport, CT, Spring 1992, pp. 52–58. World Wide Web Conference, Boston, Massachusetts, Dec. 1995, pp. 539–548.

13. T. Berners-Lee and R. Cailliau. World-Wide Web. In Proceedings of Computing in 27. F. Buschmann and R. Meunier. A system of patterns. Coplien and Schmidt (eds.), High Energy Physics 92, Annecy, France, 23–27 Sep. 1992. Pattern Languages of Program Design, Addison-Wesley, 1995, pp. 325–343.

14. T. Berners-Lee, R. Cailliau, C. Barker, and J.-F. Groff. W3 Project: Assorted 28. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. design notes. Published on the Web, Nov. 1992. Archived at Pattern-oriented Software Architecture: A system of patterns. John Wiley & Sons , Sep. 2000. 29. M. R. Cagan. The HP SoftBench Environment: An architecture for a new 15. T. Berners-Lee. Universal Resource Identifiers in WWW. Internet RFC 1630, qeneration of software tools. Hewlett-Packard Journal, 41(3), June 1990, June 1994. pp. 36–47.

16. T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, and A. Secret. The 30. J. R. Cameron. An overview of JSD. IEEE Transactions on Software Engineering, World-Wide Web. Communications of the ACM, 37(8), Aug. 1994, pp. 76–82. 12(2), Feb. 1986, pp. 222–240.

17. T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource Locators 31. R. S. Chin and S. T. Chanson. Distributed object-based programming systems. (URL). Internet RFC 1738, Dec. 1994. ACM Computing Surveys, 23(1), Mar. 1991, pp. 91–124.

18. T. Berners-Lee and D. Connolly. Hypertext Markup Language — 2.0. Internet 32. D. D. Clark and D. L. Tennenhouse. Architectural considerations for a new RFC 1866, Nov. 1995. generation of protocols. In Proceedings of ACM SIGCOMM‘90 Symposium, Philadelphia, PA, Sep. 1990, pp. 200–208. 19. T. Berners-Lee, R. T. Fielding, and H. F. Nielsen. Hypertext Transfer Protocol — HTTP/1.0. Internet RFC 1945, May 1996. 33. J. O. Coplien and D. C. Schmidt, ed. Pattern Languages of Program Design. Addison-Wesley, Reading, Mass., 1995. 20. T. Berners-Lee. WWW: Past, present, and future. IEEE Computer, 29(10), Oct. 1996, pp. 69–77. 34. J. O. Coplien. Idioms and Patterns as Architectural Literature. IEEE Software, 14(1), Jan. 1997, pp. 36–42. 21. T. Berners-Lee, R. T. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic syntax. Internet RFC 2396, Aug. 1998. 35. E. M. Dashofy, N. Medvidovic, R. N. Taylor. Using off-the-shelf middleware to implement connectors in distributed software architectures. In Proceedings of the 22. P. Bernstein. Middleware: A model for distributed systems services. 1999 International Conference on Software Engineering, Los Angeles, Communications of the ACM, Feb. 1996, pp. 86–98. May 16–22, 1999, pp. 3–12.

23. A. D. Birrell and B. J. Nelson. Implementing remote procedure call. ACM 36. F. Davis, et. al. WAIS Interface Protocol Prototype Functional Specification Transactions on Computer Systems, 2, Jan. 1984, pp. 39–59. (v.1.5). Thinking Machines Corporation, April 1990.

24. M. Boasson. The artistry of software architecture. IEEE Software, 12(6), 37. F. DeRemer and H. H. Kron. Programming-in-the-large versus programming-in- Nov. 1995, pp. 13–16. the-small. IEEE Transactions on Software Engineering, SE-2(2), June 1976, pp. 80–86.

153 154 38. E. Di Nitto and D. Rosenblum. Exploiting ADLs to specify architectural styles 51. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of induced by middleware infrastructures. In Proceedings of the 1999 International Reusable Object-oriented Software. Addison-Wesley, Reading, Mass., 1995. Conference on Software Engineering, Los Angeles, May 16–22, 1999, pp. 13–22. 52. D. Garlan and E. Ilias. Low-cost, adaptable tool integration policies for integrated 39. R. T. Fielding. Maintaining distributed hypertext infostructures: Welcome to environments. In Proceedings of the ACM SIGSOFT ‘90: Fourth Symposium on MOMspider’s web. Computer Networks and ISDN Systems, 27(2), Nov. 1994, Software Development Environments, Dec. 1990, pp. 1–10. pp. 193–204. 53. D. Garlan and M. Shaw. An introduction to software architecture. Ambriola & 40. R. T. Fielding. Relative Uniform Resource Locators. Internet RFC 1808, Tortola (eds.), Advances in Software Engineering & Knowledge Engineering, June 1995. vol. II, World Scientific Pub Co., Singapore, 1993, pp. 1–39.

41. R. T. Fielding, E. J. Whitehead, Jr., K. M. Anderson, G. Bolcer, P. Oreizy, and 54. D. Garlan, R. Allen, and J. Ockerbloom. Exploiting style in architectural design R. N. Taylor. Web-based development of complex information products. environments. In Proceedings of the Second ACM SIGSOFT Symposium on the Communications of the ACM, 41(8), Aug. 1998, pp. 84–92. Foundations of Software Engineering (SIGSOFT‘94), New Orleans, Dec. 1994, pp. 175–188. 42. R. T. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol — HTTP/1.1. Internet RFC 2616, 55. D. Garlan and D. E. Perry. Introduction to the special issue on software June 1999. [Obsoletes RFC 2068, Jan. 1997.] architecture. IEEE Transactions on Software Engineering, 21(4), Apr. 1995, pp. 269–274. 43. R. T. Fielding and R. N. Taylor. Principled design of the modern Web architecture. In Proceedings of the 2000 International Conference on Software Engineering 56. D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch, or, Why it’s hard (ICSE 2000), Limerick, Ireland, June 2000, pp. 407–416. to build systems out of existing parts. In Proceedings of the 17th International Conference on Software Engineering, Seattle, WA, 1995. Also appears as: 44. D. Flanagan. JavaScript: The Definitive Guide, 3rd edition. O’Reilly & Architectural mismatch: Why reuse is so hard. IEEE Software, 12(6), Nov. 1995, Associates, Sebastopol, CA, 1998. pp. 17–26.

45. D. Flanagan. JavaTM in a Nutshell, 3rd edition. O’Reilly & Associates, Sebastopol, 57. D. Garlan, R. Monroe, and D. Wile. ACME: An architecture description language. CA, 1999. In Proceedings of CASCON‘97, Nov. 1997.

46. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, 58. C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. E. Sink, and L. Stewart. HTTP Authentication: Basic and Digest Access Prentice-Hall, 1991. Authentication. Internet RFC 2617, June 1999. 59. S. Glassman. A caching relay for the World Wide Web. Computer Networks and 47. N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part ISDN Systems, 27(2), Nov. 1994, pp. 165–173. One: Format of Internet Message Bodies. Internet RFC 2045, Nov. 1996. 60. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. Carter, and D. Jensen. HTTP 48. N. Freed, J. Klensin, and J. Postel. Multipurpose Internet Mail Extensions (MIME) Extensions for Distributed Authoring — WEBDAV. Internet RFC 2518, Part Four: Registration Procedures. Internet RFC 2048, Nov. 1996. Feb. 1999.

49. M. Fridrich and W. Older. Helix: The architecture of the XMS distributed file 61. K. Grønbaek and R. H. Trigg. Design issues for a Dexter-based hypermedia system. IEEE Software, 2, May 1985, pp. 21–29. system. Communications of the ACM, 37(2), Feb. 1994, pp. 41–49.

50. A. Fuggetta, G. P. Picco, and G. Vigna. Understanding code mobility. IEEE 62. B. Hayes-Roth, K. Pfleger, P. Lalanda, P. Morignot, and M. Balabanovic. A Transactions on Software Engineering, 24(5), May 1998, pp. 342–361. domain-specific software architecture for adaptive intelligent systems. IEEE Transactions on Software Engineering, 21(4), Apr. 1995, pp. 288–301.

155 156 63. J. Heidemann, K. Obraczka, and J. Touch. Modeling the performance of HTTP 76. W. C. Loerke. On Style in Architecture. F. Wilson, Architecture: Fundamental over several transport protocols. IEEE/ACM Transactions on Networking, 5(5), Issues, Van Nostrand Reinhold, New York, 1990, pp. 203–218. Oct. 1997, pp. 616–630. 77. D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and W. Mann. 64. K. Holtman and A. Mutz. Transparent content negotiation in HTTP. Internet Specification and analysis of system architecture using Rapide. IEEE Transactions RFC 2295, Mar. 1998. on Software Engineering, 21(4), Apr. 1995, pp. 336–355.

65. P. Inverardi and A. L. Wolf. Formal specification and analysis of software 78. D. C. Luckham and J. Vera. An event-based architecture definition language. architectures using the chemical abstract machine model. IEEE Transactions on IEEE Transactions on Software Engineering, 21(9), Sep. 1995, pp. 717–734. Software Engineering, 21(4), Apr. 1995, pp. 373–386. 79. A. Luotonen and K. Altis. World-Wide Web proxies. Computer Networks and 66. ISO/IEC JTC1/SC21/WG7. Reference Model of Open Distributed Processing. ISDN Systems, 27(2), Nov. 1994, pp. 147–154. ITU-T X.901: ISO/IEC 10746-1, 07 June 1995. 80. P. Maes. Concepts and experiments in computational reflection. In Proceedings of 67. M. Jackson. Problems, methods, and specialization. IEEE Software, 11(6), OOPSLA ‘87, Orlando, Florida, Oct. 1987, pp. 147–155. [condensed from Software Engineering Journal], Nov. 1994. pp. 57–62. 81. J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying distributed software 68. R. Kazman, L. Bass, G. Abowd, and M. Webb. SAAM: A method for analyzing architectures. In Proceedings of the 5th European Software Engineering the properties of software architectures. In Proceedings of the 16th International Conference (ESEC‘95), Sitges, Spain, Sep. 1995, pp. 137–153. Conference on Software Engineering, Sorrento, Italy, May 1994, pp. 81–90. 82. J. Magee and J. Kramer. Dynamic structure in software architectures. In 69. R. Kazman, M. Barbacci, M. Klein, S. J. Carrière, and S. G. Woods. Experience Proceedings of the Fourth ACM SIGSOFT Symposium on the Foundations of with performing architecture tradeoff analysis. In Proceedings of the 1999 Software Engineering (SIGSOFT‘96), San Francisco, Oct. 1996, pp. 3–14. International Conference on Software Engineering, Los Angeles, May 16–22, 1999, pp. 54–63. 83. F. Manola. Technologies for a Web object model. IEEE Internet Computing, 3(1), Jan.–Feb. 1999, pp. 38–47. 70. N. L. Kerth and W. Cunningham. Using patterns to improve our architectural vision. IEEE Software, 14(1), Jan. 1997, pp. 53–59. 84. H. Maurer. HyperWave: The Next-Generation Web Solution. Addison-Wesley, Harlow, England, 1996. 71. R. Khare and S. Lawrence. Upgrading to TLS within HTTP/1.1. Internet RFC 2817, May 2000. 85. M. J. Maybee, D. H. Heimbigner, and L. J. Osterweil. Multilanguage interoperability in distributed systems: Experience Report. In Proceedings 18th 72. G. E. Krasner and S. T. Pope. A cookbook for using the Model-View-Controller International Conference on Software Engineering, Berlin, Germany, Mar. 1996. user interface paradigm in Smalltalk-80. Journal of Object Oriented Programming, 1(3), Aug.–Sep. 1988, pp. 26–49. 86. N. Medvidovic and R. N. Taylor. A framework for classifying and comparing architecture description languages. In Proceedings of the 6th European Software 73. D. Kristol and L. Montulli. HTTP State Management Mechanism. Internet Engineering Conference held jointly with the 5th ACM SIGSOFT Symposium on RFC 2109, Feb. 1997. the Foundations of Software Engineering, Zurich, Switzerland, Sep. 1997, pp. 60–76. 74. P. B. Kruchten. The 4+1 View Model of architecture. IEEE Software, 12(6), Nov. 1995, pp. 42–50. 87. N. Medvidovic. Architecture-based Specification-time Software Evolution. Ph.D. Dissertation, University of California, Irvine, Dec. 1998. 75. D. Le Métayer. Describing software architectural styles using graph grammars. IEEE Transactions on Software Engineering, 24(7), July 1998, pp. 521–533. 88. N. Medvidovic, D. S. Rosenblum, and R. N. Taylor. A language and environment for architecture-based software development and evolution. In Proceedings of the

157 158 1999 International Conference on Software Engineering, Los Angeles, 102. D. L. Parnas. On the criteria to be used in decomposing systems into modules. May 16–22, 1999, pp. 44–53. Communications of the ACM, 15(12), Dec. 1972, pp. 1053–1058.

89. A. Mockus, R. T. Fielding, and J. Herbsleb. A case study of open source software 103. D. L. Parnas. Designing software for ease of extension and contraction. IEEE development: The Apache server. In Proceedings of the 2000 International Transactions on Software Engineering, SE-5(3), Mar. 1979. Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. 263–272. 104. D. L. Parnas, P. C. Clements, and D. M. Weiss. The modular structure of complex systems. IEEE Transactions on Software Engineering, SE-11(3), 1985, 90. J. Mogul, R. Fielding, J. Gettys, and H. Frystyk. Use and Interpretation of HTTP pp. 259–266. Version Numbers. Internet RFC 2145, May 1997. 105. D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. 91. R. T. Monroe, A. Kompanek, R. Melton, and D. Garlan. Architectural Styles, ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992, pp. 40–52. Design Patterns, and Objects. IEEE Software, 14(1), Jan. 1997, pp. 43–52. 106. J. Postel and J. Reynolds. TELNET Protocol Specification. Internet STD 8, 92. M. Moriconi, X. Qian, and R. A. Riemenscheider. Correct architecture refinement. RFC 854, May 1983. IEEE Transactions on Software Engineering, 21(4), Apr. 1995, pp. 356–372. 107. J. Postel and J. Reynolds. File Transfer Protocol. Internet STD 9, RFC 959, 93. H. F. Nielsen, J. Gettys, A. Baird-Smith, E. Prud'hommeaux, H. Lie, and C. Lilley. Oct. 1985. Network Performance Effects of HTTP/1.1, CSS1, and PNG. Proceedings of ACM SIGCOMM ’97, Cannes, France, Sep. 1997. 108. D. Pountain and C. Szyperski. Extensible software systems. Byte, May 1994, pp. 57–62. 94. H. F. Nielsen, P. Leach, and S. Lawrence. HTTP extension framework, Internet RFC 2774, Feb. 2000. 109. R. Prieto-Diaz and J. M. Neighbors. Module interconnection languages. Journal of Systems and Software, 6(4), Nov. 1986, pp. 307–334. 95. H. Penny Nii. Blackboard systems. AI Magazine, 7(3):38–53 and 7(4):82–107, 1986. 110. J. M. Purtilo. The Polylith software bus. ACM Transactions on Programming Languages and Systems, 16(1), Jan. 1994, pp. 151–174. 96. Object Management Group. Object Management Architecture Guide, Rev. 3.0. Soley & Stone (eds.), New York: J. Wiley, 3rd ed., 1995. 111. M. Python. The Architects Sketch. Monty Python’s Flying Circus TV Show, Episode 17, Sep. 1970. Transcript at . and Specification (CORBA 2.1). , Aug. 1997. 112. J. Rasure and M. Young. Open environment for image processing and software 98. P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software development. In Proceedings of the 1992 SPIE/IS&T Symposium on Electronic evolution. In Proceedings of the 1998 International Conference on Software Imaging, Vol. 1659, Feb. 1992. Engineering, Kyoto, Japan, Apr. 1998. 113. S. P. Reiss. Connecting tools using message passing in the Field environment. 99. P. Oreizy. Decentralized software evolution. Unpublished manuscript (Phase II IEEE Software, 7(4), July 1990, pp. 57–67. Survey Paper), Dec. 1998. 114. D. S. Rosenblum and A. L. Wolf. A design framework for Internet-scale event 100. V. N. Padmanabhan and J. C. Mogul. Improving HTTP latency. Computer observation and notification. In Proceedings of the 6th European Software Networks and ISDN Systems, 28, Dec. 1995, pp. 25–35. Engineering Conference held jointly with the 5th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Zurich, Switzerland, Sep. 1997, 101. D. L. Parnas. Information distribution aspects of design methodology. In pp. 344–360. Proceedings of IFIP Congress 71, Ljubljana, Aug. 1971, pp. 339–344.

159 160 115. R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon. Design and 128. R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whitehead Jr., J. E. Robbins, implementation of the Sun network filesystem. In Proceedings of the Usenix K. A. Nies, P. Oreizy, and D. L. Dubrow. A component- and message-based Conference, June 1985, pp. 119–130. architectural style for GUI software. IEEE Transactions on Software Engineering, 22(6), June 1996, pp. 390–406. 116. M. Shapiro. Structure and encapsulation in distributed systems: The proxy principle. In Proceedings of the 6th International Conference on Distributed 129. W. Tephenhart and J. J. Cusick. A unified object topology. IEEE Software, 14(1), Computing Systems, Cambridge, MA, May 1986, pp. 198–204. Jan. 1997, pp. 31–35.

117. M. Shaw. Toward higher-level abstractions for software systems. Data & 130. W. Tracz. DSSA (domain-specific software architecture) pedagogical example. Knowledge Engineering, 5, 1990, pp. 119–128. Software Engineering Notes, 20(3), July 1995, pp. 49–62.

118. M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Zelesnick. 131. A. Umar. Object-Oriented Client/Server Internet Environments. Prentice Hall Abstractions for software architecture and tools to support them. IEEE PTR, 1997. Transactions on Software Engineering, 21(4), Apr. 1995, pp. 314–335. 132. S. Vestal. MetaH programmer’s manual, version 1.09. Technical Report, 119. M. Shaw. Comparing architectural design styles. IEEE Software, 12(6), Nov. Honeywell Technology Center, Apr. 1996. 1995, pp. 27–41. 133. J. Waldo, G. Wyant, A. Wollrath, and S. Kendall. A note on distributed 120. M. Shaw. Some patterns for software architecture. Vlissides, Coplien & Kerth computing. Technical Report SMLI TR-94-29, Sun Microsystems Laboratories, (eds.), Pattern Languages of Program Design, Vol. 2, Addison-Wesley, 1996, Inc., Nov. 1994. pp. 255–269. 134. L. Wall, T. Christiansen, and R. L. Schwartz. Programming Perl, 2nd ed. O’Reilly 121. M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging & Associates, 1996. Discipline. Prentice-Hall, 1996. 135. E. J. Whitehead, Jr., R. T. Fielding, and K. M. Anderson. Fusing WWW and link 122. M. Shaw and P. Clements. A field guide to boxology: Preliminary classification of server technology: One approach. In Proceedings of the 2nd Workshop on Open architectural styles for software systems. In Proceedings of the Twenty-First Hypermedia Systems, Hypertext’96, Washington, DC, Mar. 1996, pp. 81–86. Annual International Computer Software and Applications Conference (COMPSAC‘97), Washington, D.C., Aug. 1997, pp. 6–13. 136. A. Wolman, G. Voelker, N. Sharma, N. Cardwell, M. Brown, T. Landray, D. Pinnel, A. Karlin, and H. Levy. Organization-based analysis of Web-object 123. A. Sinha. Client-server computing. Communications of the ACM, 35(7), July 1992, sharing and caching. In Proceedings of the 2nd USENIX Conference on Internet pp. 77–98. Technologies and Systems (USITS), Oct. 1999.

124. K. Sollins and L. Masinter. Functional requirements for Uniform Resource Names. 137. W. Zimmer. Relationships between design patterns. Coplien and Schmidt (eds.), Internet RFC 1737, Dec. 1994. Pattern Languages of Program Design, Addison-Wesley, 1995, pp. 345–364.

125. S. E. Spero. Analysis of HTTP performance problems. Published on the Web, 138. H. Zimmerman. OSI reference model — The ISO model of architecture for open , 1994. systems interconnection. IEEE Transactions on Communications, 28, Apr. 1980, pp. 425–432. 126. K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology, 1(3), July 1992, pp. 229–268.

127. A. S. Tanenbaum and R. van Renesse. Distributed operating systems. ACM Computing Surveys, 17(4), Dec. 1985, pp. 419–470.

Roy T. Fielding: Understanding the REST Style

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

Ole Begemann

Roy fielding’s rest dissertation.

I recently read Roy Fielding’s 2000 PhD thesis, Architectural Styles and the Design of Network-based Software Architectures , in which he introduced and described REST . Here’s what I learned.

REST is almost as old as the web. I first heard of REST around 2005 while working with Rails . As mentioned, Fielding’s dissertation is from 2000, but he began developing the ideas that later became REST as early as 1994.

REST didn’t come out of nowhere. Roy Fielding wasn’t some random PhD student who sat in his ivory tower and came up with a bright idea. He was deeply involved in the web’s early development and standardization. Starting in 1994, Fielding began working at and for the World Wide Web Consortium and co-authored the HTTP 1.0 specification. In the second half of the 1990s, Fielding was the main author behind the HTTP 1.1 and URI specs. He also co-founded the Apache web server project.

REST is the web’s architecture. REST isn’t specifically about web services (i.e. machine-readable APIs that return JSON or XML). In fact, Fielding doesn’t really mention web APIs in his dissertation.

Rather, REST is first and foremost a description of the web’s architecture. The entire web is supposed to be RESTful. Specifying the web (as defined in the HTTP 1.1 spec ) is the original purpose for which REST was developed.

Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web. This work was done in conjunction with my authoring of the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI), the two specifications that define the generic interface used by all component interactions on the Web. — Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, p. 107.

The original name for REST was the “HTTP object model”:

REST was originally referred to as the “HTTP object model,” but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. — ibid., p. 109.

Architectural constraints

REST is defined through constraints. Any communication architecture that wants to call itself RESTful must abide by these constraints. You can read the full list on the Wikipedia page . Here, I’ll just list the ones I find most important.

Statelessness

Each request must contain all of the information necessary for the server to understand the request, and cannot take advantage of any stored context on the server. Session state is kept entirely on the client. Statelessness makes a service more reliable and easier to scale.

Fielding notes that cookies violate REST. To him, the presence of cookies is an unfortunate mismatch between the ideals of REST and the reality of HTTP:

An example of where an inappropriate extension has been made to the protocol [HTTP] to support features that contradict the desired properties of the generic interface is the introduction of site-wide state information in the form of HTTP cookies. Cookie interaction fails to match REST’s model of application state, often resulting in confusion for the typical browser application. — ibid., p. 130.

Cacheability

Requests and responses must include information about their cacheability. If a response is marked as cacheable, the client (or any node sitting between server and client) is allowed to reuse the data for later requests.

Fielding’s focus in the dissertation is markedly different from how developers discuss REST today. He spends a lot of time discussing web characteristics like cacheability, scalability, and the transparency of messages to intermediaries (proxies), whereas the finer points of POST vs. PUT vs. PATCH play no role in the thesis. In fact, he doesn’t mention the different HTTP methods at all.

Resources and representations

Identification of resources. Resources are the key abstraction of REST. This is in constrast to earlier specifications of the web, which used the term document for an individual “unit of content”. Resources are a more generic concept than documents. For example, having the URI to a document implies that the document exists, while a resource identifier can be valid before the resource exists (e.g. a client could pass a URI of a non-existent resource to create it).

A resource is a conceptual mapping to a set of concrete entities. For example, “today’s weather” is a valid resource, even though the concrete piece of information it maps to changes every day. Each resource has a unique identifier (usually a URI ).

Manipulation of resources through representations. Since resources can be abstract concepts, a resource itself is never directly manipulated or sent over the network. Instead, server and client exchange representations of resources. The server can (and should) offer multiple representations (e.g. JSON and XML) of the same resource. Clients tell the server which representation formats they understand.

REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types , selected dynamically based on the capabilities or desires of the recipient and the nature of the resource. Whether the representation is in the same format as the raw source, or is derived from the source, remains hidden behind the interface. — ibid., p. 87.

Self-descriptive messages

Messages include enough information to describe how their payload is to be processed (e.g. media type information must be part of each message). Also, each message completely identifies the resource it concerns (this wasn’t the case in the early days of HTTP when the HTTP header didn’t contain the hostname because it was assumed that there was a 1:1 mapping between IP addresses and hostnames).

Hypermedia as the engine of application state

The central idea behind HATEOAS is that RESTful servers and clients shouldn’t rely on a hardcoded interface (that they agreed upon through a separate channel). Instead, the server is supposed to send the set of URIs representing possible state transitions with each response, from which the client can select the one it wants to transition to. This is exactly how web browsers work:

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations. Not surprisingly, this exactly matches the user interface of a hypermedia browser. — ibid. , p. 103.

For web services where two machines talk to each other without a human controlling the interaction, I have a harder time imagining how this is supposed to work. How can you develop a client for a specific API without hardcoding some knowledge about the expected resource types? Fielding doesn’t elaborate on this in his thesis.

However, he later clarified in a 2008 blog post that APIs must be hypertext-driven to legitimately call themselves RESTful:

A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types. From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand).

I’m still not sure how anybody can develop e.g. a great mobile app under these constraints that provides a specialized user interface for one particular service. If you don’t have any out-of-band knowledge about the service you’re interacting with, you’re basically reimplementing a web browser.

PhotoKit’s data model

September 28, 2018

Splitting a Swift Sequence into head and tail

November 29, 2018

• IEEE CS Standards
• Career Center
• Subscribe to Newsletter
• IEEE Standards

• For Industry Professionals
• For Students
• Launch a New Career
• Membership FAQ
• Membership FAQs
• Membership Grades
• Special Circumstances
• Discounts & Payments
• Distinguished Contributor Recognition
• Grant Programs
• Find a Local Chapter
• Find a Distinguished Visitor
• Find a Speaker on Early Career Topics
• Technical Communities
• Collabratec (Discussion Forum)
• Start a Chapter
• My Subscriptions
• My Referrals
• Computer Magazine
• ComputingEdge Magazine
• Let us help make your event a success. EXPLORE PLANNING SERVICES
• Events Calendar
• Calls for Papers
• Conference Proceedings
• Conference Highlights
• Top 2024 Conferences
• Conference Sponsorship Options
• Conference Planning Services
• Conference Organizer Resources
• Virtual Conference Guide
• Get a Quote
• CPS Dashboard
• CPS Author FAQ
• CPS Organizer FAQ
• Find the latest in advanced computing research. VISIT THE DIGITAL LIBRARY
• Open Access
• Tech News Blog
• Author Guidelines
• Reviewer Information
• Guest Editor Information
• Editor Information
• Editor-in-Chief Information
• Volunteer Opportunities
• Video Library
• Member Benefits
• Institutional Library Subscriptions
• Advertising and Sponsorship
• Code of Ethics
• Educational Webinars
• Online Education
• Certifications
• Industry Webinars & Whitepapers
• Research Reports
• Bodies of Knowledge
• CS for Industry Professionals
• Resource Library
• Newsletters
• Women in Computing
• Digital Library Access
• Organize a Conference
• Run a Publication
• Become a Distinguished Speaker
• Participate in Standards Activities
• Peer Review Content
• Author Resources
• Publish Open Access
• Society Leadership
• Boards & Committees
• Local Chapters
• Governance Resources
• Conference Publishing Services
• Chapter Resources
• About the Board of Governors
• Board of Governors Members
• Diversity & Inclusion
• Open Volunteer Opportunities
• Award Recipients
• Student Scholarships & Awards
• Nominate an Election Candidate
• Nominate a Colleague
• Corporate Partnerships
• Conference Sponsorships & Exhibits
• Advertising
• Recruitment
• Publications
• Education & Career

Roy T. Fielding: Understanding the REST Style

In this episode.

Roy T. Fielding reminisces about his PhD dissertation, which defined the Representational State Transfer architectural style.

From Computer’s Issue 6, Vol 48 – June 2015

Charles Severance is a clinical associate professor and teaches in the School of Information at the University of Michigan, and served as Computer ‘s multimedia editor until 2018. Follow him on Twitter @drchuck or contact him at [email protected] .

Recommended by IEEE Computer Society

Resurrecting the CDC 6500 Supercomputer

Bruce schneier: the security mindset, the living computer museum, bruce schneier building cryptographic systems, anant agarwal: inside edx, anil jain: 25 years of biometric recognition, john resig: building jquery.

[ Top ] [ Prev ] [ Next ]

INTRODUCTION

Excuse me ... did you say `knives'? -- City Gent #1 (Michael Palin), The Architects Sketch [ 111 ]

As predicted by Perry and Wolf [ 105 ], software architecture has been a focal point for software engineering research in the 1990s. The complexity of modern software systems have necessitated a greater emphasis on componentized systems, where the implementation is partitioned into independent components that communicate to perform a desired task. Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how elements of a system can evolve independently, and how all of the above can be described using formal and informal notations.

A good architecture is not created in a vacuum. All design decisions at the architectural level should be made within the context of the functional, behavioral, and social requirements of the system being designed, which is a principle that applies equally to both software architecture and the traditional field of building architecture. 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 funny bit within the Monty Python sketch, cited above, is the absurd notion that an architect, when faced with the goal of designing an urban block of flats (apartments), would present a building design with all the components of a modern slaughterhouse. It might very well be the best slaughterhouse design ever conceived, but that would be of little comfort to the prospective tenants as they are whisked along hallways containing rotating knives.

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 styles are surveyed and classified according to the architectural properties they induce when applied to an architecture for network-based hypermedia. This classification is used to identify a set of architectural constraints that could be used to improve the architecture of the early World Wide Web.

Architecting the Web requires an understanding of its requirements, as we shall discuss in Chapter 4. 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 organizational boundaries. Suppliers of information services must be able to cope with the demands of anarchic scalability and the independent deployment of software components. Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentation of information retrieved from remote sites. An architecture for the Web must therefore be designed with the context of communicating large-grain data objects across high-latency networks and multiple trust boundaries.

Chapter 5 introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems. 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. 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.

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. This work was done in conjunction with my authoring of the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI), the two specifications that define the generic interface used by all component interactions on the Web.

Like most real-world systems, not all components of the deployed Web architecture obey every constraint present in its architectural design. REST has been used both as a means to define architectural improvements and to identify architectural mismatches. Mismatches occur when, due to ignorance or oversight, a software implementation is deployed that violates the architectural constraints. While mismatches cannot be avoided in general, it is possible to identify them before they become standardized. Several mismatches within the modern Web architecture are summarized in Chapter 6, along with analyses of why they arose and how they deviate from REST.

In summary, this dissertation makes the following contributions to software research within the field of Information and Computer Science:

• a framework for understanding software architecture through architectural styles, including a consistent set of terminology for describing software architecture;
• a classification of architectural styles for network-based application software by the architectural properties they would induce when applied to the architecture for a distributed hypermedia system;
• REST, a novel architectural style for distributed hypermedia systems; and,
• application and evaluation of the REST architectural style in the design and deployment of the architecture for the modern World Wide Web.

My background is a bit odd: I was conceived in New Zealand and born in Laguna Beach , California . Although most of my schooling has been in the U.S., I was taught how to read during a school term in Auckland . My father is an emeritus professor in Social Sciences at UC Irvine, which is why I have been raised a Yank. I was born in September 1965, during the first week of classes of the year UCI was established, so you might say that the two of us grew up together (except for the three years I spent studying Physics and International Politics at Reed College ). I am part Maori , Kiwi , Yank, Irish, Scot, Brit, and California beach bum . Like I said, a bit odd.

Most of the rest can be seen in my vita .

I was a Visiting Scholar at MIT/LCS during the summer of 1995, working with Tim Berners-Lee and the World Wide Web Consortium (W3C) . You can see my old W3C Home .

I was named by MIT Technology Review as one of the TR100: The top 100 young innovators for 1999 . "The 100 young visionaries who our editors and a distinguished Panel of Judges feel have the greatest potential for technological innovation in the 21st century."

The Association of Computing Machinery recently awarded the 1999 ACM Software System Award to The Apache Group for the Apache HTTP Server. I talked a bit about that honor in an interview with LinuxWorld .

On a more local note, I was named by the UCI Alumni Association as the Outstanding Graduate Student of 2000.

Other Interests

I like playing games -- especially non-betting card games (Bridge, Hearts, etc.) and obscure board games (british rails, naval war, etc.). I also like playing basketball, softball, football and going fishing. Mind you, I haven't had time to do any of these things since I started messing with the Web.

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.

To most readers it will be easy, after reading this tale, to accept Rover's theory that Man is set up deliberately as the antithesis of everything the Dogs stand for, a sort of mythical straw-man, a sociological fable. This is underlined by the recurring evidence of Man's aimlessness, his constant running hither and yon, his grasping at a way of life which constantly eludes him, possibly because he never knows exactly what he wants. --- Clifford D. Simak, "City" [Notes on the Fifth Tale], 1952.

Life is a distributed object system. However, communication among humans is a distributed hypermedia system, where the mind's intellect, voice+gestures, eyes+ears, and imagination are all components. --- Roy T. Fielding, 1998.