• Core Ideas and Technologies
• Resources and Objects (and Services tomorrow)
• MIME Types
Uniform Access - HTTP
• Main access/manipulation protocol of the Web
• A means of exchanging resource representations across the
• Request/response based interactions
• Supports a limited number of requests
• GET – retrieve a resource – no payload
• POST – send a resource to a server – payload
• PUT – update or alter a resource on a server - payload
• If the resource does not exist, the server may allow the resource to be
• DELETE – remove a resource from a server – no payload
• HEAD – find out what metadata you would get back if you
performed a GET – no payload
• OPTIONS – find out what operations are permitted on a
resource – no payload
• When a server receives a request, it returns a response
containing a response code, headers and possibly a resource
• Codes are divided into types
• 100 – 199 – informational
• 200 – 299 – success
• 300 – 399 – redirect
• 400 – 499 – client error
• 500 – 599 – server error
• 200 OK
• 201 Created
• 403 Forbidden
• 301 Redirect (with ‘Location’ header)
• 500 Internal Server Error
• The HTTP message is an envelope
• starts with headers
• Then the body (payload), if any.
GET /weather/ HTTP/1.1
HTTP/1.1 200 OK
Server: Apache/2.0.59 (Unix)
• Multipurpose Internet Mail Extensions
• not used just in email now
• The Content-Type header field points to a MIME Type
• A (slowly growing) list of known media types
• Developers/designers are encouraged to reuse MIME types
• keeping the list manageable helps interoperability
• A different approach to Object interfaces
Common HTTP Headers
• Host: the target host
• Content-Length: length (in bytes) of the resource representation
• Content-Type: MIME type of representation
• Accept: Accepted MIME type
• Transfer-Encoding: can be chunked. This means the data is sent in
chunks, rather than all in one go.
• Useful for data for which the length is not known when starting
• Content-Encoding: e.g. gzip, deflate. Allows zipping up content.
• Etag: a server defined ID for a resource
• If-Match, If-None-Match: allows conditional requests
• If-Modified-Since, If-Not-Modified: allows conditional requests
• Expect: e.g. 100-continue:
• server responds with a 100 status code if the client should continue
with the request by sending the payload.
• WWW-Authenticate: authentication challenge issued by a server
• Many Caching-related headers
HTTP Headers are extensible
• Typically start with „X-‟
• Allows application specific metadata
• Examples from Rackspace:
• X-Auth-User – user name in request
• X-Auth-Key – user API key in request
• X-Auth-Token – user token with lifetime in response
• x-roaming - is the user roaming?
• x-nokia-msisdn – user‟s mobile number in plain text
Uniform Naming - URIs
• Uniform Resource Identifier
• An identifier for a resource on the Web.
• A superset comprising URNs (Uniform Resource Name) and
URLs (Uniform Resource Location). URLs can be
dereferenced (i.e. they represent an „address‟)
• The first is a URL - it represents an address - you can GO
there - PPT spotted that
• The second is a URN - it identifies a book uniquely
• The third is a URN, but using the Jxta Protocol, one may be
able to resolve this to a URL. PPT obviously does not
• URIs can be either hierarchical or non-hierarchical.
• A non hierarchical URI is considered opaque.
• A hierarchical URI has a number of elements.
• All URIs start with a scheme element
• This example is hierarchical:
scheme host port path fragment
• This example is not hierarchical:
Resources and URIs
• Hierarchical URIs can also have a query
• This is a simplified URI generated by searching Google for
the word “web”
• q is a key to google to say the bit of the query after the = is
what I typed in.
• Query strings can contain multiple key/value pairs using an
• Experiment - change the value after the q=. Add &hl=ja to the end
of the URI and see what happens
Resources and URIs
• Resources have state but not operations over
• This is supported through URIs
• The scheme of the URI determines the operations
permitted on a resource.
• By exposing representations of resources at URIs
with different schemes, you offer different
operations on that resource.
• Term coined by Roy Fielding in his PhD dissertation
• A PhD thesis that has actually had an impact!!!
• ReST is an architectural style derived from looking at
the Web and what makes it scalable
• It is a client/server architectural style in which
clients retrieve representations of resources.
When a new resource is retrieved, the state of the
client, e.g., the browser, is changed.
• The term is now heavily used and misused
• ReST != HTTP
• Not all the Web is ReSTful
• Primary constraints
• interactions are stateless
• reduces network load
• HTTP headers support lots of caching policies
• Uniform Interface
• MIME types
• Allows servers to act as gateways to areas of the network for
• Allows evolution of parts of the network to happen incrementally without
affecting the whole network
• e.g. Applets, SWF
• Interactions on the Web are usually stateless
• Resources have (represent) state, but the interactions do not
• When I query Google, each query happens in isolation. There is
no state preserved at the server regarding my query, even if I
move through a number of results pages
• Experiment: add &start=20 to the end of your query
• What happens? You move to a new URI which is independent
of the previous URI. (Look at the Gooooooogle links at the
bottom of the page)
• The Cookie is typically used to represent interaction
• Cookie Header is an opaque pointer to state
• Stored at the client
• Understood by the server – the state of interactions is on the
server – not ReSTful
Caching and Linkability
• Allows resources to be stored and retrieved locally, or closer to
the source of the request
• This saves on bandwidth
• Is a form of load balancing
• Is possible because of the resource abstraction.
• Caching also applies to storage outside of the Web via URIs -
in desktop applications, on TV, newspapers, billboards, human
• Web Architecture (Vol 1): It is a strength of Web Architecture
that links can be made and shared; a user who has found an
interesting part of the Web can share this experience just by
republishing a URI.
• Makes the Web a web
Caching and Linkability
• Linkability and cacheability are achievable through two primary qualities
• URIs being „addressable‟
• I can share them, publish them knowing others will get the same
result as me when they de-reference the URI.
• A certain longevity to URIs - If I link to a resource today, will it still
be there tomorrow?
• Safe and idempotent interactions
• Safe interactions are those with no side-effects.
• the user is not to be held accountable for the result of the interaction.
• I am not entering into a contract or agreeing to terms and
conditions when I follow a link.
• If this were the case, how could you be sure that you were not at a
deeper level within the domain, having unknowingly bypassed the
terms an conditions page? – Servers use redirects for this.
• Idempotent interactions. No matter how many times the identical
request is repeated, it does not change the side-effects of the
• separation of resource from representation
• What you see is not the actual thing, but a
representation. Things may have multiple
• manipulation of resources by representations
• Changing the representation may induce a change in
the state of the resource itself
• self-descriptive messages
• Allows each message to be independent
• No need to track state changes across multiple
• hypermedia as the engine of application state (?)
• Hypermedia is a medium that allows non-linear progression
• A page with links - its up to you where you go.
• So state is only perceived and controlled by the client
“Hypermedia as the engine of
Every GET to Google is
Google doesn’t perceive
your state changes
Possible next states
The client chooses the next
Only the client percieves the
continuum of states
• The Web core concepts
• Uniform Access
• stateless interactions
• state at the client side