Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture”
Roy T. Fielding Adobe Richard N. Taylor University of California, Irvine Justin R. Erenkrantz Bloomberg Michael M. Gorlick University of California, Irvine Jim Whitehead University of California, Santa Cruz Rohit Khare Google Peyman Oreizy Dynamic Variable LLC Outline
1. The Story of REST § Early history of the Web § What REST is (and is not) § Contemporary influences 2. Work inspired by REST § Decentralization § Generalization § Secure computation 3. Reflections on REST § Investing in entrepreneurial students § Role of Software Engineering research
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 2 Original proposal for the World Wide Web
IBM Computer GroupTalk conferencing
Hyper for example Card uucp News ENQUIRE VAX/ NOTES Hierarchical systems
for example for example unifies A Proposal Linked "Mesh" CERNDOC information describes
describes includes includes C.E.R.N This describes document division "Hypertext"
refers group group includes describes to wrote
section
Hypermedia etc Tim Comms Berners-Lee ACM
[Berners-Lee, 1989]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 3 The Web is an application integration system
IBM Computer GroupTalk conferencing
Hyper for example Card uucp News ENQUIRE VAX/ NOTES Hierarchical systems
for example for example unifies A Proposal Linked "Mesh" CERNDOC information describes
[Berners-Lee, 1989]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 4 describes includes includes C.E.R.N This describes document division "Hypertext"
refers group group includes describes to wrote
section
Hypermedia etc Tim Comms Berners-Lee ACM
A bit of context 23,517 Aug 2017: 1,800,566,882 (76,564x)
10,022
2,738
623 130 Jun 93 Dec 93 Jun 94 Dec 94 Jun 95 Public WWW servers [Matthew Gray]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 5 A bit of context 23,517 Aug 2017: 1,800,566,882 (76,564x) Using the Web
HTTP editor
Relative URLs
wwwstat
10,022
SJ IETF
Conditional GET 2nd WWW
2,738
1st WWW HTTP Object Model 623 130 Jun 93 Dec 93 Jun 94 Dec 94 Jun 95 Public WWW servers [Matthew Gray]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 5 Three (very different) perspectives of the Web
http://www.w3.org/TR/html4/
next table of contents elements attributes index Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee HTML 4.01 Specification MIT/LCS January 1997 W3C Recommendation 24 December 1999
This version: http://www.w3.org/TR/1999/REC-html401-19991224 (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, 389 pages], gzip'ed PDF file [963Kb]) Hypertext Transfer Protocol -- HTTP/1.1 Latest version of HTML 4.01: http://www.w3.org/TR/html401 Latest version of HTML 4: Status of this Memo http://www.w3.org/TR/html4 file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html This document specifies an Internet standards track protocol for the Internet community, and requests Latest version of HTML: discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official http://www.w3.org/TR/html Previous version of HTML 4.01: Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this Network Working Group T. Berners-Lee http://www.w3.org/TR/1999/PR-html40-19990824 memo is unlimited. Previous HTML 4 Recommendation: Request for Comments: 3986 W3C/MIT http://www.w3.org/TR/1998/REC-html40-19980424 Obsoletes: 2732, 2396, 1808 R. Fielding Editors: STD: 66 AbstractDay Software Dave Raggett
HTML 4 is an SGML application conforming to International StandardC ISoOp 8y87r9i g-- hSta nNdaordtice Generalized Markup Language [ISO8879]. Copyright © The Internet Society (2005). All Rights Reserved. Status of this document Abstract This section describes the status of this document at the time of its publication. Other documents may Information supersede this document. The latest status of this document series is mAai nUtaniinfoerdm a tR theeso Wur3cCe. Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every p4/o2s/0s8ib 1le2 :i0d9e AntMifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
Fielding, et al Standards Track [Page 1] Browsers Protocols
4/2/08 12:16 AM
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 6 Web Implementation (user view)
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 7 Web Implementation (origin view)
Intermediary Proxy Cache
User Agents Webservers/Gateways Application Servers Accelerator Cache Dynamic Content Centralized Data RDBMS, NFS, SAN
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 8 Web Architecture
Architecture is a vertical abstraction on implementation
User Agents $ $
$ Proxies Gateways Origin Servers
$ $ $
$ $
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 9 Web Architecture
Web protocols defne that vertical abstraction on implementation http://www.w3.org/TR/html4/
next table of contents elements attributes index Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee HTML 4.01 Specification MIT/LCS January 1997 W3C Recommendation 24 December 1999
This version: http://www.w3.org/TR/1999/REC-html401-19991224 (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, 389 pages], gzip'ed PDF file [963Kb]) Hypertext Transfer Protocol -- HTTP/1.1 Latest version of HTML 4.01: http://www.w3.org/TR/html401 Latest version of HTML 4: Status of this Memo http://www.w3.org/TR/html4 file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html This document specifies an Internet standards track protocol for the Internet community, and requests Latest version of HTML: discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official http://www.w3.org/TR/html Previous version of HTML 4.01: Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this Network Working Group T. Berners-Lee http://www.w3.org/TR/1999/PR-html40-19990824 memo is unlimited. Previous HTML 4 Recommendation: Request for Comments: 3986 W3C/MIT http://www.w3.org/TR/1998/REC-html40-19980424 Obsoletes: 2732, 2396, 1808 R. Fielding Editors: STD: 66 AbstractDay Software Dave Raggett
HTML 4 is an SGML application conforming to International StandardC IoSOp 8y8r7i9g --h Sta nNdaordtice Generalized Markup Language [ISO8879]. Copyright © The Internet Society (2005). All Rights Reserved. Status of this document Abstract This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is mAa inUtnaiifnoerdm a tR tehseo Wur3cCe .Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every p4o/2s/s0i8b l1e2 :i0d9e nAtMifier. This specification does not define a generative grammarProtocols for URIs; that task is performed by the individual specifications of each URI scheme.
Fielding, et al Standards Track [Page 1]
4/2/08 12:16 AM
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 10 So, which one is the Web?
http://www.w3.org/TR/html4/
next table of contents elements attributes index Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee HTML 4.01 Specification MIT/LCS January 1997 W3C Recommendation 24 December 1999
This version: http://www.w3.org/TR/1999/REC-html401-19991224 (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, 389 pages], gzip'ed PDF file [963Kb]) Hypertext Transfer Protocol -- HTTP/1.1 Latest version of HTML 4.01: http://www.w3.org/TR/html401 Latest version of HTML 4: Status of this Memo http://www.w3.org/TR/html4 file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html This document specifies an Internet standards track protocol for the Internet community, and requests Latest version of HTML: discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official http://www.w3.org/TR/html Previous version of HTML 4.01: Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this Network Working Group T. Berners-Lee http://www.w3.org/TR/1999/PR-html40-19990824 memo is unlimited. Previous HTML 4 Recommendation: Request for Comments: 3986 W3C/MIT http://www.w3.org/TR/1998/REC-html40-19980424 Obsoletes: 2732, 2396, 1808 R. Fielding Editors: STD: 66 AbstractDay Software Dave Raggett
HTML 4 is an SGML application conforming to International StandardC ISoOp 8y87r9i g-- hSta nNdaordtice Generalized Markup Language [ISO8879]. Copyright © The Internet Society (2005). All Rights Reserved. Status of this document Abstract This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is mAai nUtaniinfoerdm a tR theeso Wur3cCe. Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every p4/o2s/0s8ib 1le2 :i0d9e AntMifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
Fielding, et al Standards Track [Page 1] Browsers Protocols
4/2/08 12:16 AM
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 11 So, which one is the Web?
All of them!
The Web is a World-Wide System: constantly running, always changing, anarchically accessed, and independently deployed.
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 12 Outline
1. The Story of REST § Early history of the Web § What REST is (and is not) § Contemporary influences 2. Work inspired by REST § Decentralization § Generalization § Secure computation 3. Reflections on REST § Investing in entrepreneurial students Roy T. Fielding. 2000. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. § Role of Software Engineering research http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Roy T. Fielding and Richard N. Taylor. 2000. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd Int’l Conference on Software Engineering. IEEE, Limerick, Ireland, 407–416. Roy T. Fielding and Richard N. Taylor. 2002. Principled Design of the Modern Web Architecture. ESEC/FSE’17, September 8, 2017, Paderborn, Germany ACM Transactions on Internet Technology 2, 2 (May 2002), 115–150. HATEOAS????
•One of REST’s four architectural constraints •The constraint RESTafarians struggle most with BUT… •The MOST IMPORTANT one… since hypermedia applications are the POINT of REST!
Copyright © 2012, ZapThink, a Dovèl Technologies Company Why talk about my definition of REST?
Because What is REST Anyway?
• Representational State REST Transfer (REST) is a style of software architecture for has become a distributed hypermedia systems such as the World Wide Web BUZZWORD • Roy Fielding There’s nothing particularly wrong with that… looked at the Web unless you happen to be me… and saw that it was good or working with me
Copyright © 2012, ZapThink, a Dovèl Technologies Company
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 14
5 Architectural Styles
§ A horizontal abstraction across multiple architectures (vertical abstractions) § names a repeated architectural pattern Ionic Order § defined by its design constraints § chosen for the properties they induce
§ REST is an architectural style § for network-based applications § to induce a specific set of architectural properties § that were desired for the World Wide Web
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 15 REST is an accumulation of design constraints l a
y p e ro replicated r gr e am uniform interface d ma separated ble RR CS LS VM U i nt er pr m oc ed on-demand stateless es ia mobile simple si te ng visible $ CSS LCS COD
reliable shared extensible reusable cacheable scalable multi- C$SS LC$SS org. LCODC$SS REST
ESEC/FSE’17, September 8, 2017, Paderborn, Germany Figure 5-9. REST Deriva16tion by Style Constraints
the disadvantages) of the optional constraints when they are known to be in effect for some
realm of the overall system. For example, if all of the client software within an
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
downloadable Java classes. At the same time, however, the organization’s firewall may
prevent the transfer of Java applets from external sources, and thus to the rest of the Web
it will appear as if those clients do not support code-on-demand. An optional constraint
allows us to design an architecture that supports the desired behavior in the general case,
but with the understanding that it may be disabled within some contexts.
5.1.8 Style Derivation Summary
REST consists of a set of architectural constraints chosen for the properties they induce on
candidate architectures. Although each of these constraints can be considered in isolation,
describing them in terms of their derivation from common architectural styles makes it
85 REST is an accumulation of design constraints
Constraint l a
y p e ro replicated r gr e am uniform interface d ma separated ble RR CS LS VM U i nt er pr m oc ed on-demand stateless es ia mobile simple si te ng visible $ CSS LCS COD
reliable shared extensible reusable cacheable scalable multi- C$SS LC$SS org. LCODC$SS REST
ESEC/FSE’17, September 8, 2017, Paderborn, Germany Figure 5-9. REST Deriva16tion by Style Constraints
the disadvantages) of the optional constraints when they are known to be in effect for some
realm of the overall system. For example, if all of the client software within an
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
downloadable Java classes. At the same time, however, the organization’s firewall may
prevent the transfer of Java applets from external sources, and thus to the rest of the Web
it will appear as if those clients do not support code-on-demand. An optional constraint
allows us to design an architecture that supports the desired behavior in the general case,
but with the understanding that it may be disabled within some contexts.
5.1.8 Style Derivation Summary
REST consists of a set of architectural constraints chosen for the properties they induce on
candidate architectures. Although each of these constraints can be considered in isolation,
describing them in terms of their derivation from common architectural styles makes it
85 REST is an accumulation of design constraints
Property l a
y p e ro replicated r gr e am uniform interface d ma separated ble RR CS LS VM U i nt er pr m oc ed on-demand stateless es ia mobile simple si te ng visible $ CSS LCS COD
reliable shared extensible reusable cacheable scalable multi- C$SS LC$SS org. LCODC$SS REST
ESEC/FSE’17, September 8, 2017, Paderborn, Germany Figure 5-9. REST Deriva16tion by Style Constraints
the disadvantages) of the optional constraints when they are known to be in effect for some
realm of the overall system. For example, if all of the client software within an
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
downloadable Java classes. At the same time, however, the organization’s firewall may
prevent the transfer of Java applets from external sources, and thus to the rest of the Web
it will appear as if those clients do not support code-on-demand. An optional constraint
allows us to design an architecture that supports the desired behavior in the general case,
but with the understanding that it may be disabled within some contexts.
5.1.8 Style Derivation Summary
REST consists of a set of architectural constraints chosen for the properties they induce on
candidate architectures. Although each of these constraints can be considered in isolation,
describing them in terms of their derivation from common architectural styles makes it
85 [photo by dhester: htp://mrg.bz/xVLmr1] [photo by EmmiP: htp://mrg.bz/P7BJRi] [photo by rupertjefferies: htp://mrg.bz/Y9XTf] REST’s Five Uniform Interface Constraints
1. All important resources are identified by one resource identifier mechanism § induces simple, visible, reusable, stateless communication 2. Access methods have the same semantics for all resources § induces visible, scalable, available through layered system, cacheable, and shared caches 3. Resources are manipulated through the exchange of representations § induces simple, visible, reusable, cacheable, and evolvable (information hiding) 4. Representations are exchanged via self-descriptive messages § induces visible, scalable, available through layered system, cacheable, and shared caches § induces evolvable via extensible communication 5. Hypertext as the engine of application state § induces simple, visible, reusable, and cacheable through data-oriented integration § induces evolvable (loose coupling) via late binding of application transitions
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 20 Deep dive into the hypermedia constraint
Hypertext as the Engine of Application State
* R o y S0 S1 S2 S3 *
each state can be dynamic each transition can be redirected
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 21 The client only needs to know one state and its transitions!
* R o y S0 S1 S S * Follow Your Nose
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 22 The client only needs to know one state and its transitions!
* R o y S0 S1 S2 S * Follow Your Nose
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 23 The client only needs to know one state and its transitions!
* R o y S0 S S2 S3 * Follow Your Nose
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 24 The client only needs to know one state and its transitions!
* R o y S S S S3 * Follow Your Nose
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 25 Outline
1. The Story of REST § Early history of the Web § What REST is (and is not) § Contemporary influences 2. Work inspired by REST § Decentralization § Generalization § Secure computation 3. Reflections on REST § Investing in entrepreneurial students § Role of Software Engineering research
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
DeltaV All resources: WebDAV Web server
N resource resource collection 1 M 1 1 § N M Distributed Authoring and Versioning M 1 property body § Returning to the Web's roots 1 1 1 predecessor set * revision N versioned resource M N M § N 1 Resources vs Representations vs Metadata M 1 HTML link 1 * § Stateless Interaction vs Session Locks history 1
1 1 § M Overwhelmed by commercial demands activity baseline history working workspace 1 1 1 1 1 1 resource resource M 1 1 1 1 M 1 § XML, Locks, remote data model 1 1 parent * 1 M 1 1 N 1 1 workspace § Moved away from REST constraints, 1 revision set * working * predecessor set * resource set child * but helped enlighten and refine them 1 workspace 1
current * E. James Whitehead, Jr. “World Wide Web Distributed Authoring and M activity 1 Versioning (WebDAV): An Introduction.” StandardView, Vol. 5, No. 1, March 1997, pages 3-8. versioned * 1 baseline Key: 1 Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen, HTTP Extensions for Distributed Authoring - WEBDAV. Microsoft, U.C. Irvine, Netscape, Novell, containment (by reference, on container) containment (unordered inclusion) Internet Proposed Standard RFC 2518. February, 1999. (multiple containment, single membership, (single containment, single unordered, containment relationship on container, membership, unordered, inclusion, E. James Whitehead, Jr. and Yaron Goland. 2004. The WebDAV Property delete only removes container) delete removes all contained items) Design. Software, Practice and Experience 34 (2004), 135–161. inheritance * denotes a property containment (ordered inclusion) (single containment, single stores membership, ordered, inclusion, ESEC/FSE’17, September 8, 2017, Paderborn, Germany 27 delete removes all contained items)
Figure 32 – Data model of the DeltaV versioning and configuration management extensions to WebDAV. The data model is based on revision –05 of the DeltaV protocol specification [31], and depicts advanced versioning. Many properties are not shown on this diagram to reduce visual clutter. Properties shown in this diagram represent containment relationships between entities.
194 Dynamic Software Architectures
§ How do you make adaptability easier? § Independent post-deployment evolvability § Expose the application’s architecture § Allow third-parties to evolve application by changing architecture § Verify changes against semantic annotations on the system model § with assistance of external analysis modules § if change is okay, apply it to the implementation; else, take appropriate action; notify, prevent, …
Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. 2008 Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion 2008). ACM, 899-910. (Most Influential Paper Award for ICSE 1998)
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 28 Outline
1. The Story of REST § Early history of the Web § What REST is (and is not) § Contemporary influences 2. Work inspired by REST § Decentralization § Generalization § Secure computation 3. Reflections on REST § Investing in entrepreneurial students § Role of Software Engineering research
ESEC/FSE’17, September 8, 2017, Paderborn, Germany New challenges for real-time network-based applications
6.2 Alternative Approaches to Decentralization § By 2000, there was a boom Master-slave Centralized Systems Consensus-based styles styles The challengein ofreal-time decentralization applications: recurs at many layers REST+P REST of abstraction in§ Push, computing, Peer-to-Peer, from hardware Publish/ to software: AsynchronousSubscribe, VLSI. As Instantsemiconductor Messaging, performance and increases, it willInternet-Scale become impossible Event to Notification… distribute a clock signal across a processor die, much less an entire system REST+E A+REST R+REST REST+D bus. This requires§ REST new kindshad ofgaps ‘self-timed’ for real-time: circuits [41]. Distributed Systems Control theory§ One-shot:. The study no retryof feedback if response systems, lost also known as cybernetics, resulted in rules for assessing ARREST § signals and estimatingOne-to-one: state with no observerconcurrent variables groups [40]. Internetworking.§ One-way: The breakthrough no asynchronous that permits links inter- ARREST+E ARREST+D connection of§ Latencyautonomous & LANs Agency is the end-to-endconcerns hypo- Estimated Systems thesis: the notion that even an unreliable core can be used Rohit Khare and Richard N. Taylor. 2004. Extending the REpresentational agency boundary "now horizon" to synthesize reliableState Transfer services, Architectural Styleeven for Decentralizedwithout signaling.Systems. In Middleware.Proceedings Application of the 26th International integration, Conference on Software even Engineering inside a ARRESTED (ICSE’04). IEEE Computer Society, Edinburgh, Scotland, UK, 428–437. Consensus-free Peer-to-peer single organization,(Distinguished faces Paper awardbarriers for ICSE of2004) interoperability and http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf styles Decentralized Systems styles performance that led to a vast array of design patterns for ESEC/FSE’17, September 8, 2017, Paderborn, Germany 31 message-oriented & event-based communication [38]. Figure 5: Diagram summarizing our four new architectural Mobile Systems. Caching and replication are optimistic styles, derived from four capabilities added to REST. strategies for managing inconsistency in disconnected operation, such as Bayou [7] or the Coda filesystem [25]. we enforce ACID transactions by further extending REST with end-to-end D ecision functions that enable each Software Architecture. Other researchers in the field has also described styles for managing latency, such as component to serialize all updates (ARREST+D). processing real-time news and data streams [35]. The alternative to simultaneous agreement is decen- tralization: permitting independent agents to make their 7. Conclusions own decisions. This requires accommodating four intrinsic sources of uncertainty that arise when communi- In this paper, we presented: a formal definition of cating with remote agencies: loss, congestion, delay, and decentralization; an analysis of the limitations of consen- disagreement. Their corresponding constraints are B est- sus-based software architectural styles; derivation of new effort data transfer, E fficient summarization of data to be architectural styles that can enforce the required proper- sent, A pproximate estimates of current values from data ties; and implementations that demonstrate the feasibility already received, and S elf-centered trust management. of those styles and sample applications. These so-called ‘BASE’ properties can be enforced by Figure 5 summarizes our findings. First, we identified replacing references to shared resources with end-to-end two basic factors limiting the feasibility of consensus: E stimator functions. Such extensions to REST can latency and agency. These correspond to two boundaries, increase precision of measurements of a single remote indicated by dashed lines: the ‘now horizon’ within which resource (ARREST+E); as well as increase accuracy by components can refer to the value of a variable ‘right assessing the opinions of several different agencies now’; and an agency boundary within which components (ARRESTED) to eliminate independent sources of error. can trust each other. Another way to describe them is that Furthermore, application of these styles to real-world the now horizon separates consensus-based styles from problems has been shown to be both feasible and consensus-free ones; and the agency boundary separates effective, using both open-source and commercial tools. master/slave styles from peer-to-peer ones. First, we identified four new capabilities that could be Acknowledgements combined with REST individually to induce the proper- ties we desired: events, routes, locks, and estimates. Then, This work is based on the first author’s doctoral dis- we were able to combine these to derive four new styles sertation, which also benefited from the support of Dr. optimized for each of the four types of resources. André van der Hoek and Dr. Debra J. Richardson. The For centralized resources, we enforce simultaneous authors are also grateful for the assistance of Dr. Joseph agreement by extending REST into an event-based Touch, Dr. E. James Whitehead, Dr. Roy T. Fielding, Eric architectural style by adding A synchronous event M. Dashofy, Adam Rifkin, and our anonymous reviewers. notification and R outing through active proxies This material is based upon work supported by the (ARREST). For distributed control of shared resources, National Science Foundation under Grant #0205724. Computation exchange: CREST
§ Technical triad of the Web: 1. URLs name information resources 2. Metadata used for distinguishing representations 3. HTTP defines exchanges between clients and servers § What happens when you generalize? A. CURLs name computation resources B. Metaprogamming is used for examining and describing computations C. Asynchronous protocol for peer-to-peer exchanges § CREST learned about deferring code from ‘living labs’ like Subversion § Analysis of the essential architectural decisions of the WWW, followed by generalization, opened up an entirely new space of decentralized, Internet-based applications based on computations as the fundamental concept.
Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, and Richard N. Taylor. 2007. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE’07). 255–264. CREST with security: COAST
§ Capability based security model with computation exchange § Exchange active computations among peers: Code + run-time state (reified as closures and continuations) § Novel security mechanism: Capability URL (CURL) § Dictates where computations may go § Bounds what visiting computations can do § Limits resource consumption of computations § Architectural style: COmputAtional State Transfer (COAST) § Build capability security into the architectural style § Functional capability: What can a visiting computation do? § Communication capability: With whom, when, and how often may that computation communicate?
Michael Martin Gorlick. 2016. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine. Michael M. Gorlick, Kyle Strasser, and Richard N. Taylor. 2012. COAST: An Architectural Style for Decentralized On-Demand Tailored Services. In Proceedings of 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture (WICSA/ECSA’12). 71–80. COAST: COmputAtional State Transfer
§ An Architectural Style for the Idiom of Computation Exchange 1. Service: All services are computations whose sole means of interaction is the asynchronous messaging of values, closures, continuations and binding environments 2. Execution: Each computation executes within the confines of some execution site ⟨E, B⟩ where E is an execution engine and B is a binding environment 3. Messaging: Computation x may deliver a message to computation y only if x holds a CURL u and y has the authority to read a message via u § A Capability URL (CURL) conveys the authority to communicate and is a tamper-proof cryptographic structure that can not be forged or guessed. 4. Interpretation: The interpretation of a message delivered to computation y via CURL u of y is u-dependent 5. The Service and Messaging rules confer communication by introduction: §Computation x can message computation y only if x has been introduced to y beforehand 6. Ab initio, endowment, Messaging, or Execution Outline
1. The Story of REST § Early history of the Web § What REST is (and is not) § Contemporary influences 2. Work inspired by REST § Decentralization § Generalization § Secure computation 3. Reflections on REST § Investing in entrepreneurial students § Role of Software Engineering research
ESEC/FSE’17, September 8, 2017, Paderborn, Germany Investing in entrepreneurial students, over long periods…
1990 1995 2000 2005 2010 2015 Roy Fielding HTTP/1.0 HTTP/1.1 HTTP/1.1 [std] URI Apache & ASF Jim Whitehead WebDAV WebDAV [std] Peyman Oreizy Rohit Khare KnowNow, Inc. Justin Erenkrantz Michael Gorlick IRUS & ISR TWIST Workshops 1990 1995 7.5 2000 200515 2010 22.5 2015 30
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 38 The Role of Software Engineering research
§ This is Software Engineering research § It is about Design § It is fundamentally software architecture § It is based on reflection § This is how styles....good styles... get developed: § Experience, evaluation, reflection. Wash Rinse Repeat. § The research environment was “unusual” § DARPA funding with a long leash (Thanks Bill and John!) § Lots of travel. Lots § A (mostly) accommodating university process § 9 years to Ph.D after B.S. § A highly interactive research community: UCI’s PhD students, W3C, IETF, and close industry links § Contrast with today's environment…
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 39 The Paper
§ The first version of what eventually became Principled Design of the Modern Web Architecture was submitted to FSE99 a year earlier. § It was rejected, with reviewer comments including “Over all, the originality of the paper is quite low. There is only little to learn from it.” and “- the web is old technolgoy [sic] now. - lots of jargon make the paper difficult to understand. ... - I can't find a novel lessons [sic] for software engineers in this paper.” § The ICSE 2000 paper had: § no surveys, no statistical analyses, and essentially no evaluation section. It merely stated: § “The REST architectural style has been validated through six years of development of the HTTP/1.0 and HTTP/1.1 standards, elaboration of the URI and relative URL standards, and successful deployment of several dozen independently developed, commercial-grade software systems within the modern Web architecture.’' § That work, in its multiple forms, has now been cited over 8000 times…
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 40 Acknowledgments
§ Funding § DARPA: Bill Scherlis and John Salasin; National Science Foundation; ISR’s corporate sponsors § The Web § Tim Berners-Lee, Henrik Frystyk Nielsen, Dan Connolly, Dave Raggett, and Larry Masinter § REST advocates § Mark Baker, Paul Prescod, Mike Amundsen, Leonard Richardson, Sam Ruby, and Aaron Swartz § Colleagues § Mark Ackerman, Ken Anderson, Greg Bolcer, Eric Dashofy, Nenad Medvidovic, Kari Nies, Jie Ren, Jason Robbins, David Rosenblum, and Girish Suryanarayana.
§ Thanks — § To the SIGSOFT community for the honor of this Impact Award.
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 41 Questions?
ESEC/FSE’17, September 8, 2017, Paderborn, Germany 42