Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction

1
Representational State TransferAn Architectural
Style for Distributed Hypermedia Interaction

• Roy T. Fielding
• University of California, Irvine
• http//www.ics.uci.edu/fielding/

2
Network Application Architecture

• Software architecture of a network-based app
• abstract system view and model for comparison
• communication restricted to message passing
• Defines
• how system components are allocated and
  identified
• how the components interact to form a system
• the amount and granularity of communication
  needed for interaction
• interface protocols

3
Network Performance Measures

• latency
• latent period time between stimulus and first
  indication of a response
• minimum latency ping/echo time
• throughput
• rate of data transfer
• round trips
• number of interactions per user action

4
Network Performance Measures

• overhead
• setup time to enable application-level
  interaction
• message control
• amortization
• spreading overhead across many interactions
• completion
• setup / amortization (roundtrips latency)
  (control data) / throughput

5
User-perceived Performance

• user-perceived latency impacted by
• setup overhead
• network distance x round trips
• blocking/multithreading
• collisions
• user-perceived throughput impacted by
• available network bandwidth
• message control overhead
• message buffering, layer mismatches
• loss of synchronization

6
Network Application Performance

• application ? style ? architecture ?
  implementation
• Network performance is bound by
• application requirements
• pattern of communication
• infrastructure used to communicate
• implementation of components
• The best network application performanceis
  obtained by not using the network
• disconnected operation

7
Architectural Styles

• Common patterns within system architectures
• One system may be composed of multiple styles
• Some styles are hybrids of other styles
• An architecture is an instantiation of a style
• We could equally talk about
• computer architecture
• network architecture
• software architecture Shaw/Garlan, 1993
• network-based application architecture

8
Client/Server

• most hyped, least meaningful style
• emphasizes separation of concerns
• initiators (clients) and listeners (servers)

9
Remote Session

• each client initiates a session on server
• application state kept on server
• commands are used to exchange data orchange
  session state
• flexible, interactive, easy to extend services
• scalability is a problem

10
Remote Data Access (RDA)

• Clients send database queries to remote server
• Server maintains per-client state for
  joins/trans.
• Client must know enough about data structure to
  build structure-dependent queries
• SQL commonly used to define query
• Results transferred by (proprietary) protocol

11
Pipe-and-Filter

• a.k.a., one-way data flow
• data stream is filtered through a sequence of
  components
• components do not need to know identity of peers
• components are transitive

12
Event-based Integration

• components listen to a message bus or register
  with a broker
• components do not need to know identity of peers
• separation of concerns, independent evolution
• usually not designed for high-latency networks
• poor scalability
• collisions or single point of failure

13
Distributed Objects

• Components interact as peers
• Emphasizes object management, data hiding, state
  distribution
• Strong typing is usually assumed
• identity of peer is required
• Uses EBI or brokered client/server
• Streaming not supported in general

14
Distributed Process Paradigms

• Gregory Andrews, 1991
• Heartbeat
• Probe/Echo
• Broadcast
• Token-passing
• Replicated/shared server, blackboard
• Replicated workers, bag of tasks

15
Web Architectural Style

• Web architectural style revolves around five
  fundamental notions
• resource
• representation of a resource
• communication to obtain/modify representations
• web page as an instance of application state
• engines to move from one state to the next
• browser
• spider
• any media type handler

16
What is a Resource?

• A resource can be anything that has identity
• a document or image
• a service, e.g., todays weather in Seattle
• a collection of other resources
• non-networked objects (e.g., people)
• The resource is the conceptual mapping to an
  entity or set of entities, not necessarily the
  entity that corresponds to that mapping at any
  particular point in time!

17
Representations of a Resource

• The Web is designed to manipulate and transfer
  representations of a resource
• A single resource may be associated with multiple
  representations (content negotiation)
• A representation is in the form of a media type
• provides information for this resource
• Hypermedia-aware media types
• provide potential state transitions
• Most representations are cachable

18
Representational State Transfer

• optimized for transfer of typed data streams
• caching of representations allows application
  interaction to proceed without using the network
• all components can be pipe-and-filter

19
Origin Server Model

• server provides interface to services as a
  resource hierarchy
• implementation details hidden from clients
• stateless interaction for scalability
• application interaction can be spread across
  multiple servers
• replaceable by a gateway pipe

20
Gateway Model

• appears as a normal origin server to client
• provides an interface encapsulation of other
  services
• data flow translation in both directions
• also used for high-speed caching

21
Agent Model

• holds all application state
• which allows user to manipulate it (history)
• or anticipate changes to it (link maps)
• application details hidden from server
• browser, spider, index robot, personal agent
• replaceable by a proxy pipe

22
Proxy Model

• translate multiple services into HTTP
• transform data streams according to client
  limitations (e.g., image translation)
• enforce security policies
• enable shared caching

23
Web Architecture Evolution

• Uniform Resource Identifiers
• http//www.ics.uci.edu/fielding/talks/
• mailtofielding_at_ics.uci.edu
• Access protocols
• HTTP, FTP, Gopher, ...
• Media types
• HTML, XML, applet languages
• Some architectural misfits
• HTTP cookies, HTML frames

24
Uniform Resource Identifiers

• A simple and extensible means of identifying
  resources
• Uniformity allows
• different types of resource identification within
  a single protocol element
• uniform semantic interpretation of common
  syntactic elements
• relative syntactic interpretation independent of
  scheme
• Few changes since 1991

25
Hypertext Transfer Protocol

• A protocol (syntax and semantics) for
  transferring representations of resources
• usually across the Internet using TCP
• Design goals
• speed (stateless, cachable, few round-trips)
• simplicity
• extensibility
• data (payload) independence
• A true network-based API

26
HTTP/0.9 (pre-1993)

• Absolute Simplicity
• GET /url-path
• ltTITLEgtHello Worldlt/TITLEgt
• Hello World
• No Extensibility
• only one method (GET)
• no request modifiers
• no response metadata

27
HTTP/1.0 (1993-present)

• Simple and (mostly) Extensible
• GET /Test/hello.html HTTP/1.0
• Accept text/html
• User-Agent GET/5 libwww-perl/0.40
• HTTP/1.0 200 OK
• Date Fri, 12 Jan 1996 010249 GMT
• Server Apache/1.0.5
• Content-type text/html
• Content-length 38
• Last-modified Wed, 10 Jan 1996 01
• ltTITLEgtHellolt/TITLEgt
• Hello out there!

28
HTTP/1.0 Deficiencies

• No complete specification until end of 94
• No minimum standard for compliance
• Poor network behavior
• one request per connection
• no reliable transfer of dynamic content
• no control over response caching
• failed to anticipate proxies and gateways
• created huge demand for vanity addresses
• misuse/misunderstanding of MIME

29
HTTP/1.1

• Culmination of two years work, RFC2068
• with Henrik Frystyk, Jim Gettys, Jeff Mogul
• designed at UCI and W3C expanded in IETF
• Improved Reliability
• chunked transfer of dynamic content
• recognition of proxy and gateway requirements
• explicit cachability of responses
• Improved Network Behavior
• persistent connections
• virtual hosts (many names, one address)

30
HTTP/1.1 (1997-????)

• Less Simple, More Extensible, but Compatible
• GET /Test/hello.html HTTP/1.1
• Host kiwi.ics.uci.edu8080
• User-Agent GET/7 libwww-perl/5.40
• HTTP/1.1 200 OK
• Date Fri, 07 Jan 1997 154009 GMT
• Server Apache/1.2b6
• Content-type text/html
• Transfer-Encoding chunked
• Etag a797cd-465af
• Cache-control max-age3600
• Vary Accept-Language

31
HTTP/1.x Deficiencies

• MIME is too verbose (overhead per message)
• Control mixed with metadata
• Metadata restricted to header or trailer
• Meta-metadata requires encapsulation of entire
  message
• Fixed request/response ordering can block
  progress
• Lack of multiplexing prevents getting important
  part of multiple representations first

32
HTTP/2.x

• Tokenized transfer of common fields
• reducing bandwidth usage, latency
• removal of MIME syntax limitations
• self-descriptive for extensions
• Multiplexing control, data, metadata streams
• reducing desire for multiple connections
• enabling multi-protocol connections
• per-stream priority or credit mechanism
• Layered streams for meta-metadata, encryption...

33
Media Types

• Web architecture is designed to be media type
  independent
• but we can only use what agents will consume
• leading to a chicken-and-egg adoption problem
• HTML is still the lingua franca
• difficult to extend semantics, rendering
• wasteful to extend syntactically
• no mechanism for alternatives
• ECMAscript, DynamicHTML, applets

34
XML to the rescue?

• X for extensible
• self-descriptive syntax
• semantics by reference (doctype, namespaces)
• rendering by reference (style sheets)
• An XML representation is an object turned
  inside-out, with behavior-by-reference
• However, network application performance will
  demand standards for domain-specific doctypes and
  style sheets

35
Conclusions

• Web architectural style inherits from
• client/server separation of concerns,
  scalability
• pipe-and-filter streams, intermediaries,
  encapsulation
• distributed objects methods, message structure
• Advantages of representational state transfer
• application state controlled by the user agent
• composed of representations from multiple servers
• representations can be cached, shared
• matches hypermedia interaction model of combining
  information and control

36
Future Work

• Dynamic application architectures
• Architectural analysis and performance bounds
• Impact of future network architectures (ATM)
• Balancing secure transfer with firewall
  visibility
• Protocol for manipulating resource mappings
• HTTP-NG (W3C/Xerox PARC)
• rHTTP (UCI)

37
Questions?

• Slides available late next week
• http//www.ics.uci.edu/fielding/talks/webarch_98
  05/