Designing a new protocol for the Web

Transcript Designing a new protocol for the Web

waka: A replacement for HTTP
Roy T. Fielding, Ph.D.
Chief Scientist, Day Software
Director, The Apache Software Foundation
Co-founder, Apache HTTP Server Project
Elected member, W3C Technical Architecture Group
http://www.apache.org/~fielding/
1
How should we design a new
application protocol?
 Define the architectural style
 Even a generic protocol must choose one
model for evaluation of efficiency, or
choose to be inefficient for all applications
 Document desired architectural properties
 Identify the architectural elements
 Components, connectors, data
 Interfaces, transports, media types
 Specify protocol
 Semantics = component interaction
 Syntax = efficiency/extensibility
waka: A replacement for HTTP
November 2002
2
But what about Web Services?






ONC / DCE RPC
COM / DCOM
CORBA
J2EE
Web Services
.NET
 They have all tried to solve the same
problem …
waka: A replacement for HTTP
November 2002
3
EAI - the hard way
app5
app1
app2
app3
app4
n1
4 applications = 6 integrations
5 applications = 10 integrations
i
 n
i1
6 applications = 15 integrations
waka: A replacement for HTTP
November 2002
4
EAI - the Web way
waka: A replacement for HTTP
November 2002
5
High-level Web Requirements
 Low entry-barrier
 Hypermedia User Interface
 Simple protocols for authoring and data transfer
 Extensibility
 Multiple organizational boundaries
 Anarchic scalability
 Heterogeneous platforms
 Gradual and fragmented change (deployment)
 Distributed Hypermedia System
 Efficient for large data transfers
 Sensitive to user-perceived latency
 Capable of disconnected operation
waka: A replacement for HTTP
November 2002
6
REST Architectural Style
 My dissertation work at UC Irvine
 available on Web [Fielding 2000]
 independent discussion on RESTWiki [Baker et al.]
 An architectural style can be used to define
the principles behind the Web architecture
such that they are visible to future architects
 A style is a named set of constraints on
architectural elements
 REST was used to guide definition and
implementation of modern Web architecture
 modifications to HTTP and URI
 implementations in Apache, libwww-perl, …
waka: A replacement for HTTP
November 2002
7
REST Style Derivation Graph
Uniform
Interface
Layered
System
Client
Server
Virtual
Machine
Replicated
Repository
LCS
Stateless
Code-On-Demand
Cache
REST
waka: A replacement for HTTP
November 2002
8
REST Process View
$
$
$
$
$
$




$
$
Layered Client-Server
Uniform Interface (like Pipe and Filter)
Stateless, Cacheable Communication
Optional Code-on-Demand
waka: A replacement for HTTP
November 2002
9
REST Uniform Interface
 Pictures are not sufficient
 We must define constraints that enforce a
uniform interface
 Five primary interface constraints
 Resource is unit of identification
 Resource is manipulated through exchange
of representations
 Resource-generic interaction semantics
 Self-descriptive messaging
 Hypermedia is engine of application state
waka: A replacement for HTTP
November 2002
10
Hypertext Transfer Protocol
 The role of HTTP in Web Architecture





Extend uniform interface across the net
Minimize user-perceived latency
Enable layered processing
Enable caching
Enable extension and evolution
 Already survived a decade of evolution
 1991-93:
 1993-97:
 1996-now:
waka: A replacement for HTTP
HTTP/0.9 [Berners-Lee]
HTTP/1.0 [RFC 1945]
HTTP/1.1 [RFC 2068/2616]
November 2002
11
HTTP Message Syntax
GET /Test/hello.html HTTP/1.1\r\n
Host: kiwi.ics.uci.edu:8080\r\n
Accept: text/html, text/*, */*\r\n
User-Agent: GET/7 libwww-perl/5.40\r\n
\r\n
HTTP/1.1 200 OK\r\n
Date: Thu, 09 Mar 2000 15:40:09 GMT\r\n
Server: Apache/1.3.12\r\n
Content-Type: text/html\r\n
Content-Language: en\r\n
Transfer-Encoding: chunked\r\n
Etag: “a797cd-465af”\r\n
Cache-control: max-age=3600\r\n
Vary: Accept-Language\r\n
\r\n
4090\r\n
<HTML><HEAD>
…
waka: A replacement for HTTP
November 2002
12
HTTP Current Problems
 HTTP/1.1 was limited by pre-existing syntax




Overhead of MIME-style message syntax
Head-of-line blocking on interactions
Metadata unable to come after data
Server can’t send unsolicited responses
 Messages are not fully self-descriptive
 Extensions don’t indicate scope, mandatory/optional
 Response messages don’t indicate request
 Low-power and bandwidth-sensitive devices
 More severely impacted than desktop browsers
 Typical solution: impose a gateway
 device-specific, proprietary protocol
 loss of fidelity in communication due to evolution
 fails when devices roam across networks
waka: A replacement for HTTP
November 2002
13
It’s time for a new standard
 A new protocol standard could solve HTTP’s
current problems in a generic way
 However, building consensus around a new
protocol isn't easy
 How do we differentiate from existing protocols,
particularly those that are supposedly generic?
 How do we decide among conflicting design
alternatives for a new protocol?
 How do we design such that the protocol can be
deployed in a heterogeneous environment?
 I use the REST architectural style as a guide
waka: A replacement for HTTP
November 2002
14
Waka
 A new protocol designed to match
efficiency of REST architectural style
 Why “waka”?
 Mäori word (pronounced “wah-kah”) for
the outrigger canoes used to travel safely
on the Pacific Ocean, across hundreds of
islands, to Aotearoa (New Zealand)
 One of the few four-letter words suitable
for a protocol name
 Deployable within an HTTP connection
 via the HTTP/1.1 Upgrade header field
 defined mapping to HTTP/1.1 for proxies
waka: A replacement for HTTP
November 2002
15
New Request Semantics
 RENDER method
 display/print/speak this representation
 MONITOR method
 notify me when resource state changes
 Authoring methods (DAV simplified)
 elimination of non-resource identifiers
 reintroduction of PATCH
 Request control data
 request identifier
 transaction identifier
 relative priority
waka: A replacement for HTTP
November 2002
16
New Response Semantics
 Self-descriptive binding to the request
 Echo of request id, method, target URI
 Cache key explicitly described
 Caches no longer need to save request fields
 Caches don’t have to guess about Vary info
 Enables asynchronous transport
 Response indicates authoritative or not
 Semantics formerly in status code
 Unsolicited Responses
 Cache invalidation messages
 Multicast event notices
waka: A replacement for HTTP
November 2002
17
Waka Syntax
 Uniform syntax
 Regardless of message type, direction
 Padding allowed for 32/64bit alignment
 Self-descriptive




Explicit typing for message structure, fields
Indication of mandate and scope of fields
Association of metadata (control, resource, rep.)
Premature termination of request or response
 Efficient and Extensible




Tokens for all standard elements
A URI reference can be used in place of any token
Macros (client-defined syntax short-hand)
Interleaved data and metadata delivery
waka: A replacement for HTTP
November 2002
18
A work just beginning
waka
 Has not yet been fully specified
 Has not yet been implemented
 Has not yet been deployed
 Will eventually be proposed as ASF project
 Will eventually be submitted to IETF
 Will have its progress tracked:
http://www.apache.org/~fielding/waka/
waka: A replacement for HTTP
November 2002
19
20
Web Architecture
 Understanding the Web’s Success
 Design Notes of Tim Berners-Lee
 Representational State Transfer (REST)
 W3C Technical Architecture Group
 Goals
 Document existing design principles
 Identify methods for evaluating
 existing identifiers, formats, protocols
 proposals for new features
 proposals for new interaction styles
 Define new design principles
waka: A replacement for HTTP
November 2002
21
Principled Architecture Design
 Iterating over:
 Analyze system
 Focus on one phase of operation
 Choose a level of abstraction
 Identify components, connectors, data
 Establish requirements
 What must be true across phase of operation
 Select design principles
 Principles motivate architectural constraint
 Constrain the architecture
 Constraints induce architectural properties
waka: A replacement for HTTP
November 2002
22
Example Requirements
 Web as a system must exist at the
operational scale of entire societies
 no "on" or "off" switch
 system must evolve while in use
 Change is inevitable
 requires planning for evolution
 Spans multiple organizations
 changes cannot be deployed all at once
 requires gradual and fragmented change
waka: A replacement for HTTP
November 2002
23
Example Principles
 Information hiding
 a component's visibility into the implementation of
another component should be limited to what is
necessary to interoperate with its interface
 prevents unintended assumptions about component
behavior that may not hold true in the future
 applied to improve property of evolvability -independent evolution of technology over time
 Separation of concerns
 a component that performs two or more separate
activities is better implemented as two or more
components if doing so increases cohesion and
reduces coupling
 applied to improve properties of simplicity and
evolvability
waka: A replacement for HTTP
November 2002
24
Example Constraint
 Orthogonal protocols deserve
orthogonal specifications
 If one protocol uses another as data, it must not
restrict the content of that data other than as
defined by that protocol, including future
compatible revisions of that protocol.
 A specification that defines two orthogonal protocols
(including data formats) must be split into two
specifications, since otherwise the independent
evolution of those protocols will be hindered.
 Result is simpler protocols
 able to evolve independently over time
 enables system to continue operation through
gradual and fragmented change
waka: A replacement for HTTP
November 2002
25