This presentation was given to the xml-interest group Jan 12th 2004 by Harry Halpin. The outline is below. HTML slides from the talk may be found here.
REST
Representational State Transfer:
The Architectural Style of the Web
Harry Halpin
Jan 12th, 2004
Why the Web is Significant?
- This goes almost without saying!
- The Web permeates the fabric of everyday life.
- Google serves as "Everyman's oracle".
- Contrast its success with AI or NLP.
Why is the Web Significant?
- What design choices led to its widespread adoption and use?
- W3C TAG: "The WWW is a network-spanning information space of resources
interconnected by links."
- Tim BL: interoperability, evolvability, and universality.
- Want specific design choices that lead to this success.
- Abstract these design choices into a coherent architecture away from
its concrete implementation in the Web.
- These choices lie in the "middle realm" between designer and
software.
Architectural Styles
- An architecture is defined relationships among components,
connectors, and data that are constrained to achieve properties.
- A architectural style is the set of constraints that achieve a space
of architectures.
- Data: An element of information.
- Representations such as HTML documents or PNG images, resources such as URI
- Component: Abstract unit of software instructions and internal state.
- Web browsers, web servers, proxies, and gateways.
- These transform the data elements.
- Connector: Mediates communication among components (http).
- Don't change underlying data.
- Server and client APIs (libwww), HTTP Connect, SSL.
Performance as a Property
- These are almost always trade-offs between distinct properties.
- Internally, the properties often result from choices.
- Performance: Does either the system or its components work within enough time?
- Network performance is the rate of information is transferred between components.
- Number of interactions per user action and size of data elements, known or unknown
components, negotiated or non-negotiated interfaces.
- Latency: Period of time between stimulus and initial response
- Completion: Amount of time to finish action.
- Quicker latency usually results in slower completion.
- Best performance is not using network at all!
Yet More Desirable Properties
- Scalability: Large amount of components or interactions among components
- Simplicity: Map separation of concerns to functions of components
- Modifiability: Can change be made to application, particularly without restarting?
- Evolvability: Can component's implementation be changed?
- Extensibility: Can functionality be added easily to a system?
- Visibility: Can we monitor interactions among components?
- Portability: Can system run in multiple environments?
- Reliability: Do partial failures lead to system failure?
Examples of Architectural Styles
- Pipe and Filter: One-way transfer of data among component filters.
- Main constraint: Filters must be completely independent, data processing one-way.
- Advantages: Simple, reusable, evolvable, extensible.
- Disadvantages: "Invisible hand" arranges filters, lowering of network and
user-perceived performance if problem interrupts data stream, no interactivity.
- Do we have a cache? Client-Server? Peer-to-Peer? Layers? Remote Evaluation?
- Other architectural styles: Virtual Machines, Event-Based, Mobile-Agent
What the Web Wants
- Uniform Interface: heterogeneous collections of software and hardware.
- Users should not have to keep local copies of all files.
- Low Entry Barrier: Participation voluntary. Links must allow unlimited structure.
- Missing data should not disallow new data from being authored.
- Anarchic Scalability: No central control, clients cannot have knowledge of all servers
and vice versa, scale with unlimited growth of both data and users - i.e. Internet-scale.
- Minimize user-perceived latency and network interactions.
- Independent Deployment: Different implementations co-exist, deployment is mixed.
REST: Representational State Transfer
- Client-Server: Allow data to be stored away from user-interface for better
portability and independent development of components.
- Stateless: The communication between client to server is stateless.
- All communication must be completely self-describing. Easy to deal with partial failures
- Since all session state is on client, server has minimal resource commitment per client,
and so the clients can grow rapidly without server scalability issues.
- Uniform Interface: Implementation of component decoupled from function.
- Layered: Each component can only interact with single layers.
- Simple, general, extensible and evolvable, but at increase of latency due to
repetitive information being transferred in non-ideal formats.
- Can off-set by caches throughout layers.
- Code on Demand:Client can be upgraded by downloading code to increase
functionality incrementally.
More REST:
- Data are resources identified by URLs - which may just be identification or a representation.
- Since a resource is really just identification - then the representation may be static or dynamic!
- If a representation, meta-data in representation allows negotiation.
- Latency: HTML and some image formats are incrementally processed as received.
- Connectors: are defined to be stateless, having only control data. Client
asks for resource, and then server may transfer representation.
- Data is moved from server to processing client, instead of moving client to data
or let server do processing. Late-binding pull instead of push
- Server and client negotiate using shared uniform and evolving standards - like XML
REST implemented as the Web
- REST came out of development by Roy Fielding of HTTP1.0/1.1 and Relative URL
- URI:Originally designed as for a document location.
- Documents change and
should keep URI - and URIs are used for names and services.
- In REST, URI denotes abstract concepts possibly with a representation.
- URIs should change "infrequently as possible".
- URIs should not keep track of state by adding username, "http:/site/user/choice1".
- HTTP:Implements protocol versioning negotiation, extensible namespaces.
- Originally HTTP did not send full host name (problems with multiple naming authorities).
- Added a Host Header field in HTTP 1.1
- Content Negotiation added, less than .001 percent of sites use it.
Violation of REST: Cookies
- Cookies are data that are given by origin server to client by HTTP.
- The user keeps the cookie - cookie is connected to resource, not state.
- Cookies confused by changes of state, such as "Back" button!
- Data passed without sufficiently identifying its semantics - security problems!
- Cookie functionality, like shopping baskets, should be implemented via public-key
encryption and client-side components upgrade.
Why Javascript beats Java
- Java and Javascript (ECMAScript) are both code-on-demand languages for the Web.
- Java is technically superior - yet Javascript more successful on the Web!
- Javascript maps better to REST.
- Java is a compiled language, less visible and larger deployment costs!
- Javascript is embodied as visible markup in HTML has lower entry barrier.
- Less latency - Javascript can run while rest of HTML still downloading.
Is REST here to stay?
- Do current and emerging Web standards map well to REST?
- If not, which goes: them or REST?
- TAG recommends all user interactions (shopping) leave a URI "paper-trail".
- Most Semantic Web standards (RDF, OWL) build on REST.
- Although apparently the inference engines should be client-side.
- Web Services though violates REST - interactions replace "quasi-static information
space" and focus on "enterprise wide and inter-enterprise operations"(Tim BL, Web Services).
- Accountability takes center-stage, unlike in REST.
- Increased use of peer-to-peer technology - like file-sharing.
- Blur between client and server, move from static to dynamic.
Lessons from REST
- Build anarchic scalability into system from beginning.
- Keep processing (state) on client.
- Server only serves static representations, i.e. stateless.
- Let client pull representations of its own choosing.
- Choose higher user-perceived latency when possible.
- Keep deployment costs and learning cost low, maximize visibility and
evolvability.