Representational
State Transfer
COMP6017 Topics on Web Services
Dr Nicholas Gibbins – nmg@[Link]
2012-2013
Resource Oriented Model
2
Representational State Transfer
Original design for the Web did not have a formal architecture
– Network issues with early HTTP affected scalability
– Nature of application interactions on the Web changed (images, etc)
– Limited support for shared caching
Architectural style that parallels and informs the design of
HTTP/1.1
– Described in a thesis by Roy Fielding (Day Software, co-founder of the
Apache Software Foundation, co-author of HTTP and URI RFCs)
REST Constraints
4
Constraints
Fielding identifies five key constraints (and one optional
constraint) for REST:
– Client-Server
– Stateless
– Cacheable
– Layered system
– Uniform interface
– Code on demand
Client-Server
Separation of concerns:
– user interface (client)
– data storage (server)
+Improves portability of user interface
+Improves scalability by simplifying server
+Allows components to evolve separately
Stateless
Each request from client to server must contain all of the
information necessary to understand the request
– No context is stored on the server
– Session state is kept entirely on the client
+Improves visibility (can consider each request in isolation)
+Improves reliability (easier to recover from partial failures)
+Improves scalability (reduces server resource usage)
- Increases per-interaction overhead
7
Cache
Response data must be labelled as cacheable or non-cacheable
– If cacheable, client may reuse response data for later requests
+Allows some interactions to be eliminated
+Reduces average latency of interactions
- Stale data reduces reliability
8
Uniform Interface
Uniform interface between components
– Identification of resources
– Manipulation of resources through representations
– Self-descriptive messages
– Hypermedia as the engine of application state
+Improves visibility of interactions
+Encourages independent evolvability
- Degrades efficiency (depending on optimisation)
9
Layered System
System components have no knowledge of components
beyond those with which they directly interact
– Encapsulate legacy services
– Introduce intermediaries
+Limits system complexity
+Improves scalability (load balancing)
- Adds latency and overhead (offset by caching)
10
Code on Demand (optional)
Client functionality extended by downloading and executing
code
– Applets
– Scripts
+Improves extensibility
- Reduces visibility
11
Architectural
Elements
12
Data Elements
• Resources
• Resource identifiers
• Representations
• Representation metadata
• Control data
Connectors
• Client
• Server
• Cache
• Resolver
• Tunnel
14
Components
• Origin server
• Gateway
• Proxy
• User agent
15
Further Reading
Architectural Styles and the Design of Network-based
Software Architectures (Ch 4-6)
[Link]
16
Introduction to
RESTful
Web Services
17
REST beyond the Web architecture
• Discussion of Web Services has concentrated on W3C Web
Services Architecture (+WS-I, etc)
• Discussion of REST has concentrated on the W3C Web
Architecture
• We can apply the constraints from REST to the design of
Web Services
– Better fit between the two architectures
The Richardson Maturity Model
• Model of RESTful maturity
• REST constraints made concrete,
in context of Web technology Hypermedia
stack
HTTP
URI
19
Level Zero
• Single well-known endpoint
• Uses HTTP as a transport only
Hypermedia
• No hypermedia
HTTP
URI
20
Level Zero in Practice
• XML-RPC
• Most SOAP services
• POX
21
POX: Plain Old XML over HTTP
• Use HTTP POST to transfer XML documents between
systems
– SOAP-like, without SOAP headers, etc
– Platform independent
• Uses HTTP as a transport protocol, not an application
protocol
– HTTP metadata is ignored
22
Level One
• Multiple endpoints
• Uses HTTP as a transport only
(single verb) Hypermedia
• No hypermedia
HTTP
URI
23
Templates and Tunnelling
• URI templates
– [Link]
• URI tunneling
– Use GET for safe/idempotent operations
– Use POST otherwise
– Map existing method parameters to URI query parameters
– [Link]
24
URI Tunnelling
Sometimes Web-friendly
– Multiple URIs used to name resources
– (Sometimes) correct use of GET
but
– URIs used to encode operations, rather than identify resources
– Use of GET for non-safe operations breaches Web Architecture
principle of Safe Retrieval
25
Level Two
• Multiple endpoints, identifying
resources
• Understands HTTP (multiple Hypermedia
verbs)
• No hypermedia
HTTP
URI
26
Mapping CRUD to HTTP
Operation HTTP Verb
Create POST to a URI, creates new subordinate
resource
Read GET, returns representation
Update PUT, providing new representation
Delete DELETE, removes resource
27
Level Three
• Multiple endpoints, identifying
resources
• Understands HTTP (multiple Hypermedia
verbs)
• Uses links to communicate
protocols (shared state) HTTP
URI
28
HATEOAS
• Hypermedia as the engine of application state
• Resource representations include links to related resources
– Links that represent a transition to a possible future state of the
current resource
– Link types used to indicate operations (HTTP verbs) that may be used
on the indicated resources
– State transitions constitute application protocol
29
Next Lecture
• REST in Practice!
30
Running Example: Restbucks
• Online coffee shop
– Customer (client) orders coffee from barista
customise check status
order pay payment add to in order
submitted queue preparation
received deliver completed
cancel
canceled
31