WAKA-Replacement for HTTP

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 waka: A replacement for HTTP November 2002 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 … waka: A replacement for HTTP November 2002 3 EAI - the hard way app5 app1 app2 app3 app4 n 1 4 applications = 6 integrations 5 applications = 10 integrations i i 1  n 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 HTTP/0.9 [Berners-Lee] HTTP/1.0 [RFC 1945] HTTP/1.1 [RFC 2068/2616] November 2002 11  Already survived a decade of evolution  1991-93:  1993-97:  1996-now: waka: A replacement for HTTP 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 … 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/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 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 18  Efficient and Extensible waka: 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/ waka: A replacement for HTTP November 2002 19 20 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 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