Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture”
Roy T. Fielding AdobeRichard N. Taylor University of California, IrvineJustin R. Erenkrantz BloombergMichael M. Gorlick University of California, IrvineJim Whitehead University of California, Santa CruzRohit Khare GooglePeyman Oreizy Dynamic Variable LLC
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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
2
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Original proposal for the World Wide Web
3
Thisdocument"Hypertext"
Linkedinformation
Hypermedia
CERNDOC
ENQUIRE
TimBerners-Lee
section
group
C.E.R.N
wrote
division
Hierarchicalsystems
for example
for example
describes
includes
for example
AProposal"Mesh"
HyperCard uucp
News
IBMGroupTalk
VAX/NOTES
Computerconferencing
describes
includes
includes
CommsACM
describesrefers
to
describes
etc
group
unifies
[Berners-Lee, 1989]
Thisdocument"Hypertext"
Linkedinformation
Hypermedia
CERNDOC
ENQUIRE
TimBerners-Lee
section
group
C.E.R.N
wrote
division
Hierarchicalsystems
for example
for example
describes
includes
for example
AProposal"Mesh"
HyperCard uucp
News
IBMGroupTalk
VAX/NOTES
Computerconferencing
describes
includes
includes
CommsACM
describesrefers
to
describes
etc
group
unifies
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
The Web is an application integration system
4
[Berners-Lee, 1989]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Jun 93 Dec 93 Jun 94 Dec 94 Jun 95
130623
2,738
10,022
23,517
Public WWW servers [Matthew Gray]
A bit of context
5
Aug 2017: 1,800,566,882 (76,564x)
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Jun 93 Dec 93 Jun 94 Dec 94 Jun 95
130623
2,738
10,022
23,517
Public WWW servers [Matthew Gray]
A bit of context
5
Aug 2017: 1,800,566,882 (76,564x)
Using the Web
wwwstat
Conditional GET
1st WWW
Relative URLs
2nd WWW
HTTP editor
SJ IETF
HTTP Object Model
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Three (very different) perspectives of the Web
6
Information
http://www.w3.org/TR/html4/
4/2/08 12:09 AM
next table of contents elements attributes index
HTML 4.01 Specification
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])
Latest version of HTML 4.01:
http://www.w3.org/TR/html401
Latest version of HTML 4:
http://www.w3.org/TR/html4
Latest version of HTML:
http://www.w3.org/TR/html
Previous version of HTML 4.01:
http://www.w3.org/TR/1999/PR-html40-19990824
Previous HTML 4 Recommendation:
http://www.w3.org/TR/1998/REC-html40-19980424
Editors:
Dave Raggett <[email protected]>
Arnaud Le Hors, W3C
Ian Jacobs, W3C
Copyright ©1997-1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use
and software licensing rules apply.
Abstract
This specification defines the HyperText Markup Language (HTML), the publishing language of the
World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition
to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32]
and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style
sheets, better printing facilities, and documents that are more accessible to users with disabilities.
HTML 4 also takes great strides towards the internationalization of documents, with the goal of making
the Web truly World Wide.
HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard
Generalized Markup Language [ISO8879].
Status of this document
This section describes the status of this document at the time of its publication. Other documents maysupersede this document. The latest status of this document series is maintained at the W3C.
Fielding, et al Standards Track [Page 1]
Network Working Group R. FieldingRequest for Comments: 2068 UC IrvineCategory: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997
Hypertext Transfer Protocol -- HTTP/1.1
Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official
Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this
memo is unlimited.
AbstractThe Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative,
hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for
many tasks, such as name servers and distributed object management systems, through extension of its
request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification
defines the protocol referred to as “HTTP/1.1”.
file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html
4/2/08 12:16 AM
Network Working Group T. Berners-Lee
Request for Comments: 3986 W3C/MIT
Obsoletes: 2732, 2396, 1808 R. Fielding
STD: 66 Day Software
Updates: 1738 L. Masinter
Category: Standards Track Adobe Systems
January 2005
Uniform Resource Identifier (URI): Generic Syntax
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the currentedition of the “Internet Official Protocol Standards” (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright © The Internet Society (2005). All Rights Reserved.
Abstract
A Uniform Resource 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 possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
ProtocolsBrowsers
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Web Implementation (user view)
7
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Web Implementation (origin view)
8
Application Servers Dynamic Content
Centralized Data RDBMS, NFS, SAN
Webservers/GatewaysAccelerator Cache
User Agents
IntermediaryProxy Cache
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Web Architecture
9
$
$
$
$
$
$
$
$User Agents
Proxies Gateways Origin Servers
Architecture is a vertical abstraction on implementation
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Web Architecture
10
http://www.w3.org/TR/html4/
4/2/08 12:09 AM
next table of contents elements attributes index
HTML 4.01 Specification
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])
Latest version of HTML 4.01:
http://www.w3.org/TR/html401
Latest version of HTML 4:
http://www.w3.org/TR/html4
Latest version of HTML:
http://www.w3.org/TR/html
Previous version of HTML 4.01:
http://www.w3.org/TR/1999/PR-html40-19990824
Previous HTML 4 Recommendation:
http://www.w3.org/TR/1998/REC-html40-19980424
Editors:
Dave Raggett <[email protected]>
Arnaud Le Hors, W3C
Ian Jacobs, W3C
Copyright ©1997-1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use
and software licensing rules apply.
Abstract
This specification defines the HyperText Markup Language (HTML), the publishing language of the
World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition
to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32]
and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style
sheets, better printing facilities, and documents that are more accessible to users with disabilities.
HTML 4 also takes great strides towards the internationalization of documents, with the goal of making
the Web truly World Wide.
HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard
Generalized Markup Language [ISO8879].
Status of this document
This section describes the status of this document at the time of its publication. Other documents maysupersede this document. The latest status of this document series is maintained at the W3C.
Fielding, et al Standards Track [Page 1]
Network Working Group R. FieldingRequest for Comments: 2068 UC IrvineCategory: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997
Hypertext Transfer Protocol -- HTTP/1.1
Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official
Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this
memo is unlimited.
AbstractThe Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative,
hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for
many tasks, such as name servers and distributed object management systems, through extension of its
request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification
defines the protocol referred to as “HTTP/1.1”.
file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html
4/2/08 12:16 AM
Network Working Group T. Berners-Lee
Request for Comments: 3986 W3C/MIT
Obsoletes: 2732, 2396, 1808 R. Fielding
STD: 66 Day Software
Updates: 1738 L. Masinter
Category: Standards Track Adobe Systems
January 2005
Uniform Resource Identifier (URI): Generic Syntax
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the currentedition of the “Internet Official Protocol Standards” (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright © The Internet Society (2005). All Rights Reserved.
Abstract
A Uniform Resource 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 possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
Protocols
Web protocols define that vertical abstraction on implementation
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
So, which one is the Web?
Information
http://www.w3.org/TR/html4/
4/2/08 12:09 AM
next table of contents elements attributes index
HTML 4.01 Specification
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])
Latest version of HTML 4.01:
http://www.w3.org/TR/html401
Latest version of HTML 4:
http://www.w3.org/TR/html4
Latest version of HTML:
http://www.w3.org/TR/html
Previous version of HTML 4.01:
http://www.w3.org/TR/1999/PR-html40-19990824
Previous HTML 4 Recommendation:
http://www.w3.org/TR/1998/REC-html40-19980424
Editors:
Dave Raggett <[email protected]>
Arnaud Le Hors, W3C
Ian Jacobs, W3C
Copyright ©1997-1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use
and software licensing rules apply.
Abstract
This specification defines the HyperText Markup Language (HTML), the publishing language of the
World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition
to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32]
and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style
sheets, better printing facilities, and documents that are more accessible to users with disabilities.
HTML 4 also takes great strides towards the internationalization of documents, with the goal of making
the Web truly World Wide.
HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard
Generalized Markup Language [ISO8879].
Status of this document
This section describes the status of this document at the time of its publication. Other documents maysupersede this document. The latest status of this document series is maintained at the W3C.
Fielding, et al Standards Track [Page 1]
Network Working Group R. FieldingRequest for Comments: 2068 UC IrvineCategory: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997
Hypertext Transfer Protocol -- HTTP/1.1
Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official
Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this
memo is unlimited.
AbstractThe Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative,
hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for
many tasks, such as name servers and distributed object management systems, through extension of its
request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification
defines the protocol referred to as “HTTP/1.1”.
file://localhost/Users/fielding/ws/labs-webarch/uri/rfc/rfc3986.html
4/2/08 12:16 AM
Network Working Group T. Berners-Lee
Request for Comments: 3986 W3C/MIT
Obsoletes: 2732, 2396, 1808 R. Fielding
STD: 66 Day Software
Updates: 1738 L. Masinter
Category: Standards Track Adobe Systems
January 2005
Uniform Resource Identifier (URI): Generic Syntax
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the currentedition of the “Internet Official Protocol Standards” (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright © The Internet Society (2005). All Rights Reserved.
Abstract
A Uniform Resource 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 possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
ProtocolsBrowsers
11
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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.
12
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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
Roy T. Fielding. 2000. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 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. ACM Transactions on Internet Technology 2, 2 (May 2002), 115–150.
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
RESTWhy talk about my definition of REST?
5
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
What is REST Anyway?
Copyright © 2012, ZapThink, a Dovèl Technologies Company
• Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web
• Roy Fielding looked at the Web and saw that it was good
BUZZWORD
Because
has become a
There’s nothing particularly wrong with that… unless you happen to be me… or working with me
14
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Architectural Styles
§A horizontal abstraction across multiple architectures (vertical abstractions) § names a repeated architectural pattern § 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
15
Ionic Order
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
REST is an accumulation of design constraints
16
85
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
Figure 5-9. REST Derivation by Style Constraints
RR CS LS VM U
CSS LCS COD$
C$SS LC$SS LCODC$SS REST
replicated
on-demand
separated
layered
mobile
uniform interface
stateless
shared
intermediate
processing
cacheable
extensible
simple
reusable
scalable
reliable
multi-org.
visible
programmable
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
REST is an accumulation of design constraints
16
85
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
Figure 5-9. REST Derivation by Style Constraints
RR CS LS VM U
CSS LCS COD$
C$SS LC$SS LCODC$SS REST
replicated
on-demand
separated
layered
mobile
uniform interface
stateless
shared
intermediate
processing
cacheable
extensible
simple
reusable
scalable
reliable
multi-org.
visible
programmable
Constraint
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
REST is an accumulation of design constraints
16
85
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
Figure 5-9. REST Derivation by Style Constraints
RR CS LS VM U
CSS LCS COD$
C$SS LC$SS LCODC$SS REST
replicated
on-demand
separated
layered
mobile
uniform interface
stateless
shared
intermediate
processing
cacheable
extensible
simple
reusable
scalable
reliable
multi-org.
visible
programmable
Property
[pho
to b
y Em
miP
: http
://m
rg.b
z/P7
BJRi
]
[pho
to b
y ru
pert
jeffe
ries:
http:
//m
rg.b
z/Y9
XThf]
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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
20
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Deep dive into the hypermedia constraint
Hypertext as the Engine of Application State
each state can be dynamiceach transition can be redirected
21
S0 S2S1 S3R o y*
*
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
The client only needs to know one state and its transitions!
Follow Your Nose
22
S0 SS1 SR o y*
*
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
The client only needs to know one state and its transitions!
Follow Your Nose
23
S0 S2S1 SR o y*
*
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
The client only needs to know one state and its transitions!
Follow Your Nose
24
S0 S2S S3R o y*
*
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
The client only needs to know one state and its transitions!
Follow Your Nose
25
S SS S3R o y*
*
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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
WebDAV
§Distributed Authoring and Versioning § Returning to the Web's roots § Resources vs Representations vs Metadata § Stateless Interaction vs Session Locks
§Overwhelmed by commercial demands § XML, Locks, remote data model § Moved away from REST constraints, but helped enlighten and refine them
27
194
DeltaV
Key:
containment (unordered inclusion) (single containment, single membership, unordered, inclusion, delete removes all contained items)
containment (by reference, on container) (multiple containment, single membership, unordered, containment relationship on container, delete only removes container)
stores
resource
inheritance
Web server
1
M
1
1 property body
collection MN
containment (ordered inclusion) (single containment, single membership, ordered, inclusion, delete removes all contained items)
HTML link
1
M
1
1
All resources:
resource
workspace
revision versioned resource
activity working resource
history resource
history *
predecessor set *
baseline
predecessor set *revision set * working resource set
*
parent workspace
*
current activity
*
child workspace
*
1 1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
M
N
M
1
1
1 1
M
N N M
1
1
1
M
M
1
* denotes a property
M
N
N
M
versioned baseline
*
1
1
1
1
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.
E. James Whitehead, Jr. “World Wide Web Distributed Authoring and Versioning (WebDAV): An Introduction.” StandardView, Vol. 5, No. 1, March 1997, pages 3-8.
Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen, HTTP Extensions for Distributed Authoring - WEBDAV. Microsoft, U.C. Irvine, Netscape, Novell, Internet Proposed Standard RFC 2518. February, 1999.
E. James Whitehead, Jr. and Yaron Goland. 2004. The WebDAV Property Design. Software, Practice and Experience 34 (2004), 135–161.
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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, …
28
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
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
§By 2000, there was a boom in real-time applications:§ Push, Peer-to-Peer, Publish/Subscribe, Instant Messaging, and Internet-Scale Event Notification…
§REST had gaps for real-time:§ One-shot: no retry if response lost§ One-to-one: no concurrent groups§ One-way: no asynchronous links
§Latency & Agency concerns
31
6.2 Alternative Approaches to Decentralization
The challenge of decentralization recurs at many layers
of abstraction in computing, from hardware to software:
Asynchronous VLSI. As semiconductor performance
increases, it will become impossible to distribute a clock
signal across a processor die, much less an entire system
bus. This requires new kinds of ‘self-timed’ circuits [41].
Control theory. The study of feedback systems, also
known as cybernetics, resulted in rules for assessing
signals and estimating state with observer variables [40].
Internetworking. The breakthrough that permits inter-
connection of autonomous LANs is the end-to-end hypo-
thesis: the notion that even an unreliable core can be used
to synthesize reliable services, even without signaling.
Middleware. Application integration, even inside a
single organization, faces barriers of interoperability and
performance that led to a vast array of design patterns for
message-oriented & event-based communication [38].
Mobile Systems. Caching and replication are optimistic
strategies for managing inconsistency in disconnected
operation, such as Bayou [7] or the Coda filesystem [25].
Software Architecture. Other researchers in the field
has also described styles for managing latency, such as
processing real-time news and data streams [35].
7. Conclusions
In this paper, we presented: a formal definition of
decentralization; an analysis of the limitations of consen-
sus-based software architectural styles; derivation of new
architectural styles that can enforce the required proper-
ties; and implementations that demonstrate the feasibility
of those styles and sample applications.
Figure 5 summarizes our findings. First, we identified
two basic factors limiting the feasibility of consensus:
latency and agency. These correspond to two boundaries,
indicated by dashed lines: the ‘now horizon’ within which
components can refer to the value of a variable ‘right
now’; and an agency boundary within which components
can trust each other. Another way to describe them is that
the now horizon separates consensus-based styles from
consensus-free ones; and the agency boundary separates
master/slave styles from peer-to-peer ones.
First, we identified four new capabilities that could be
combined with REST individually to induce the proper-
ties we desired: events, routes, locks, and estimates. Then,
we were able to combine these to derive four new styles
optimized for each of the four types of resources.
For centralized resources, we enforce simultaneous
agreement by extending REST into an event-based
architectural style by adding A synchronous event
notification and R outing through active proxies
(ARREST). For distributed control of shared resources,
we enforce ACID transactions by further extending REST
with end-to-end D ecision functions that enable each
component to serialize all updates (ARREST+D).
The alternative to simultaneous agreement is decen-
tralization: permitting independent agents to make their
own decisions. This requires accommodating four
intrinsic sources of uncertainty that arise when communi-
cating with remote agencies: loss, congestion, delay, and
disagreement. Their corresponding constraints are B est-
effort data transfer, E fficient summarization of data to be
sent, A pproximate estimates of current values from data
already received, and S elf-centered trust management.
These so-called ‘BASE’ properties can be enforced by
replacing references to shared resources with end-to-end
E stimator functions. Such extensions to REST can
increase precision of measurements of a single remote
resource (ARREST+E); as well as increase accuracy by
assessing the opinions of several different agencies
(ARRESTED) to eliminate independent sources of error.
Furthermore, application of these styles to real-world
problems has been shown to be both feasible and
effective, using both open-source and commercial tools.
Acknowledgements
This work is based on the first author’s doctoral dis-
sertation, which also benefited from the support of Dr.
André van der Hoek and Dr. Debra J. Richardson. The
authors are also grateful for the assistance of Dr. Joseph
Touch, Dr. E. James Whitehead, Dr. Roy T. Fielding, Eric
M. Dashofy, Adam Rifkin, and our anonymous reviewers.
This material is based upon work supported by the
National Science Foundation under Grant #0205724.
ARRESTED
ARREST+E
REST+E
REST
A+REST R+REST
ARREST
ARREST+D
REST+D
"now horizon"
Consensus-basedstyles
Consensus-freestyles
REST+P
Master-slavestyles
Peer-to-peerstyles
agency boundary
Centralized Systems
Decentralized Systems
Distributed System
sEstim
ated
Sys
tem
s
Figure 5: Diagram summarizing our four new architecturalstyles, derived from four capabilities added to REST.
Rohit Khare and Richard N. Taylor. 2004. Extending the REpresentational State Transfer Architectural Style for Decentralized Systems. In Proceedings of the 26th International Conference on Software Engineering (ICSE’04). IEEE Computer Society, Edinburgh, Scotland, UK, 428–437. (Distinguished Paper award for ICSE 2004) http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf
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.
§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?
CREST with security: COAST
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
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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…
38
Roy FieldingHTTP/1.0HTTP/1.1
HTTP/1.1 [std]URI
Apache & ASFJim Whitehead
WebDAVWebDAV [std]
Peyman OreizyRohit Khare
KnowNow, Inc.Justin Erenkrantz
Michael GorlickIRUS & ISR
TWIST Workshops7.5 15 22.5 30
1990 20001995 2005 2010 2015
1990 20001995 2005 2010 2015
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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…
39
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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…40
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
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.
41
ESEC/FSE’17, September 8, 2017, Paderborn, Germany
Questions?
42
Top Related