You are on page 1of 25

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

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

3
EAI - the hard way

app5

app1 app2 app3 app4

n- 1

4 applications = 6 integrations
i >> n
i=1
5 applications = 10 integrations

6 applications = 15 integrations
4
EAI - the Web way

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

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,

7
REST Style Derivation Graph

Uniform Layered Client Virtual Replicated


Interface System Server Machine Repository

LCS Stateless Code-On-Demand Cache

REST
8
REST Process View

$ $

$ $ $

$ $

Layered Client-Server
Uniform Interface (like Pipe and Filter)
Stateless, Cacheable Communication
Optional Code-on-Demand
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

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: HTTP/0.9 [Berners-Lee]
1993-97: HTTP/1.0 [RFC 1945]
1996-now: HTTP/1.1 [RFC 2068/2616]

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>

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 cant send unsolicited responses
Messages are not fully self-descriptive
Extensions dont indicate scope, mandatory/optional
Response messages dont 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

13
Its time for a new standard

A new protocol standard could solve HTTPs


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

14
Waka

A new protocol designed to match


efficiency of REST architectural style
Why waka?
Mori 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

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

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 dont 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

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

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/

19
20
Web Architecture

Understanding the Webs 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
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

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

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

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

25