1. REST (Representational State Transfer)
Neil Ernst
Some material from Costello and Kehoe, John Cowan, Roy Fielding, Paul Prescod

2. Why REST?
“… the web is an existence proof of a massively scalable distributed system that works really well, and we can take ideas from that to build integrated systems more easily.” – Martin Fowler

3. The HTTP API HTTP provides a simple set of operations.
GET = retrieve a resource (idempotent)
POST = store a new/updated resource
PUT = store a resource at a URI (idempotent)
DELETE = remove this resource (idempotent)
The HTTP API can implement CRUD - (Create, Retrieve, Update, and Delete)
We’ll discuss ‘resource’ in a sec. PUT is often used for “update” and post for “create”, but that isn’t totally accurate.

4. Idempotence
An operation that can be applied multiple times without changing the result after the first application
E.g. floor(x) where x is a real number
Subtract average from a list of numbers
PUT/GET/DEL operations are by definition idempotent
E.g. GET does not change the resource.

5. Nouns and verbs Two choices:
RPC – model the API using verbs – the operations
E.g. setCustomer(c_id, name, address)
Must define the data elements as well
“RESTful” model the API nouns – the data representation and state – and keep ops simple
Eg. PUT issue/{id}
Leverage the scalability of the HTTP infrastructure
Caching, third-party libraries
Simplify one part of the API
The point, or one of them

6. Copyright 2005 John Cowan under GPL
Two views of POST
“POST lets you pass a whole lot of parameters and get something back, bypassing caches.”
“POST lets you create new resources that are related to old ones.”
The second is the REST attitude

7. What is REST?
" REST " was coined by Roy Fielding in his Ph.D. dissertation [1] to describe an arch. style for implementing networked systems.
[1]

8. Copyright 2005 John Cowan under GPL
REST principles
Resources are identified by uniform resource identifiers (URIs)
Resources are manipulated through their representations
Messages are self-descriptive and stateless
Multiple representations are accepted or sent
Hypertext As The Engine Of Application State (HATEOAS)
A represnetation can be many forms, but most resources only have one, and so far, it tends to be JSON. XML also common.

9. REST design criteria
Support a distributed ‘web’ of hypermedia documents numbering in the billions.
Layered separation to support independent evolution
Replication and caching to support scaling.
Universal, limited set of operations to support extensibility.
Stateless to support independent processing.

10. Why is it called "Representational State Transfer? "
Resource
Client
Fuel requirements
Maintenance schedule
...
Boeing747.html
The Client references a Web resource using a URL.
A representation of the resource is returned (in this case as an HTML document).
The representation (e.g., Boeing747.html) places the client in a new state.
When the client selects a hyperlink in Boeing747.html, it accesses another resource.
The new representation places the client application into yet another state.
Thus, the client application transfers state with each resource representation.

11. Representational State Transfer
"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."
- Roy Fielding