View
215
Download
0
Category
Tags:
Preview:
Citation preview
1
waka: A replacement for HTTP
Roy T. Fielding, Ph.D.
Chief Scientist, Day SoftwareDirector, The Apache Software FoundationCo-founder, Apache HTTP Server ProjectElected member, W3C Technical Architecture Group
http://www.apache.org/~fielding/
November 2002 2waka: A replacement for HTTP
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
November 2002 3waka: A replacement for HTTP
But what about Web Services?
ONC / DCE RPC COM / DCOM CORBA J2EE Web Services .NET
They have all tried to solve the same problem …
November 2002 4waka: A replacement for HTTP
EAI - the hard way
4 applications = 6 integrations
5 applications = 10 integrations
6 applications = 15 integrations
app1 app2 app3 app4
app5
€
ii=1
n−1
∑ >> n
November 2002 5waka: A replacement for HTTP
EAI - the Web way
November 2002 6waka: A replacement for HTTP
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
November 2002 7waka: A replacement for HTTP
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, …
November 2002 8waka: A replacement for HTTP
REST Style Derivation Graph
VirtualMachine
Code-On-DemandLCS
LayeredSystem
Stateless
ClientServer
Cache
ReplicatedRepository
REST
UniformInterface
November 2002 9waka: A replacement for HTTP
REST Process View
$
$
$
$
$
$
$
$
Layered Client-Server Uniform Interface (like Pipe and Filter) Stateless, Cacheable Communication Optional Code-on-Demand
November 2002 10waka: A replacement for HTTP
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
November 2002 11waka: A replacement for HTTP
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: HTTP/0.9 [Berners-Lee] 1993-97: HTTP/1.0 [RFC 1945] 1996-now: HTTP/1.1 [RFC 2068/2616]
November 2002 12waka: A replacement for HTTP
HTTP Message Syntax
GET /Test/hello.html HTTP/1.1\r\nHost: kiwi.ics.uci.edu:8080\r\nAccept: text/html, text/*, */*\r\n
User-Agent: GET/7 libwww-perl/5.40\r\n\r\n
HTTP/1.1 200 OK\r\nDate: Thu, 09 Mar 2000 15:40:09 GMT\r\nServer: Apache/1.3.12\r\nContent-Type: text/html\r\nContent-Language: en\r\nTransfer-Encoding: chunked\r\nEtag: “a797cd-465af”\r\nCache-control: max-age=3600\r\nVary: Accept-Language\r\n
\r\n 4090\r\n
<HTML><HEAD> …
November 2002 13waka: A replacement for HTTP
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
November 2002 14waka: A replacement for HTTP
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
November 2002 15waka: A replacement for HTTP
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
November 2002 16waka: A replacement for HTTP
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
November 2002 17waka: A replacement for HTTP
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
November 2002 18waka: A replacement for HTTP
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
November 2002 19waka: A replacement for HTTP
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/
20
November 2002 21waka: A replacement for HTTP
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
November 2002 22waka: A replacement for HTTP
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
November 2002 23waka: A replacement for HTTP
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
November 2002 24waka: A replacement for HTTP
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
November 2002 25waka: A replacement for HTTP
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
Recommended