waka A replacement for HTTP Roy T Fielding

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, W 3 C Technical Architecture Group http: //www. apache. org/~fielding/ waka: A replacement for HTTP November 2002

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 J 2 EE Web Services. NET § They have all tried to solve the same problem … waka: A replacement for HTTP November 2002 3

EAI - the hard way app 5 app 1 app 2 app 3 app 4 4 applications = 6 integrations 5 applications = 10 integrations 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/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. 1rn Host: kiwi. ics. uci. edu: 8080rn Accept: text/html, text/*, */*rn User-Agent: GET/7 libwww-perl/5. 40rn HTTP/1. 1 200 OKrn Date: Thu, 09 Mar 2000 15: 40: 09 GMTrn Server: Apache/1. 3. 12rn Content-Type: text/htmlrn Content-Language: enrn Transfer-Encoding: chunkedrn Etag: “a 797 cd-465 af”rn Cache-control: max-age=3600rn Vary: Accept-Languagern 4090rn … 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/64 bit 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

waka: A replacement for HTTP November 2002

Web Architecture § Understanding the Web’s Success § Design Notes of Tim Berners-Lee § Representational State Transfer (REST) § W 3 C 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