Waka a replacement for http l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

waka: A replacement for HTTP PowerPoint PPT Presentation


  • 208 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

waka: A replacement for HTTP

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Waka a replacement for http l.jpg

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/


How should we design a new application protocol l.jpg

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


But what about web services l.jpg

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


Eai the hard way l.jpg

app1

app2

app4

app3

EAI - the hard way

app5

4 applications = 6 integrations

5 applications = 10 integrations

6 applications = 15 integrations

waka: A replacement for HTTP


Eai the web way l.jpg

EAI - the Web way

waka: A replacement for HTTP


High level web requirements l.jpg

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


Rest architectural style l.jpg

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


Rest style derivation graph l.jpg

UniformInterface

LayeredSystem

ClientServer

VirtualMachine

ReplicatedRepository

Stateless

Code-On-Demand

LCS

Cache

REST

REST Style Derivation Graph

waka: A replacement for HTTP


Rest process view l.jpg

$

$

$

$

$

$

$

$

REST Process View

  • Layered Client-Server

  • Uniform Interface (like Pipe and Filter)

  • Stateless, Cacheable Communication

  • Optional Code-on-Demand

waka: A replacement for HTTP


Rest uniform interface l.jpg

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


Hypertext transfer protocol l.jpg

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]

waka: A replacement for HTTP


Http message syntax l.jpg

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


Http current problems l.jpg

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


It s time for a new standard l.jpg

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


Slide15 l.jpg

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


New request semantics l.jpg

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


New response semantics l.jpg

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


Waka syntax l.jpg

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


A work just beginning l.jpg

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/

A work just beginning

waka: A replacement for HTTP


Web architecture l.jpg

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


Principled architecture design l.jpg

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


Example requirements l.jpg

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


Example principles l.jpg

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


Example constraint l.jpg

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


  • Login