Reflections on the REST Architectural Style and ... · Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture” Roy T. Fielding Adobe

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


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


The Web is an application integration system

4

[Berners-Lee, 1989]


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)


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


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:


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:


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


Web Implementation (user view)

7


Web Implementation (origin view)

8

Application Servers Dynamic Content

Centralized Data RDBMS, NFS, SAN

Webservers/GatewaysAccelerator Cache

User Agents

IntermediaryProxy Cache


Web Architecture

9

$

$

$

$

$

$

$

$User Agents

Proxies Gateways Origin Servers

Architecture is a vertical abstraction on implementation


Web Architecture

10


4/2/08 12:09 AM




This version:














Editors:


Arnaud Le Hors, W3C

Ian Jacobs, W3C



Abstract


















memo is unlimited.









4/2/08 12:16 AM







January 2005


Status of this Memo


Copyright Notice


Abstract


Protocols

Web protocols define that vertical abstraction on implementation


So, which one is the Web?

Information


4/2/08 12:09 AM




This version:














Editors:


Arnaud Le Hors, W3C

Ian Jacobs, W3C



Abstract


















memo is unlimited.









4/2/08 12:16 AM







January 2005


Status of this Memo


Copyright Notice


Abstract


ProtocolsBrowsers

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.

12


Outline




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.


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


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


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



16

85















RR CS LS VM U

CSS LCS COD$


replicated

on-demand

separated

layered

mobile

uniform interface

stateless

shared

intermediate

processing

cacheable

extensible

simple

reusable

scalable

reliable

multi-org.

visible

programmable

Constraint



16

85















RR CS LS VM U

CSS LCS COD$


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 dh

este

r: htt

p://

mrg

.bz/

xVLm

r1]

http://mrg.bz/xVLmr1%5D

[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]


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


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*

*


The client only needs to know one state and its transitions!

Follow Your Nose

22

S0 SS1 SR o y*

*



Follow Your Nose

23

S0 S2S1 SR o y*

*



Follow Your Nose

24

S0 S2S S3R o y*

*



Follow Your Nose

25

S SS S3R o y*

*


Outline





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.


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)


Outline





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


Outline





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


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


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


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


Questions?

42

Reflections on the REST Architectural Style and ... · Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture” Roy T. Fielding Adobe

Documents