waka: A replacement for HTTP

1
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/

2
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

3
But what about Web Services?

• ONC / DCE RPC
• COM / DCOM
• CORBA
• J2EE
• Web Services
• .NET
• They have all tried to solve the same problem

4
EAI - the hard way
app5
4 applications 6 integrations
5 applications 10 integrations
6 applications 15 integrations
5
EAI - the Web way
6
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

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

8
REST Style Derivation Graph
9
REST Process View

• Layered Client-Server
• Uniform Interface (like Pipe and Filter)
• Stateless, Cacheable Communication
• Optional Code-on-Demand

10
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

11
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

12
HTTP Message Syntax

• GET /Test/hello.html HTTP/1.1\r\n
• Host kiwi.ics.uci.edu8080\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 154009 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-age3600\r\n
• Vary Accept-Language\r\n
• \r\n
• 4090\r\n
• ltHTMLgtltHEADgt

13
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

14
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

15
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

16
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

17
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

18
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

19
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
(No Transcript)
21
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

22
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

23
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

24
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

25
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