Representational State Transfer, or REST, has become the hip, new buzzword of Web 2.0. But what really makes an application RESTful? Is it pretty URLs? Or the use of XML over HTTP? Is it any web service that doesn't use SOAP? In all of the hype, the definition of REST has become clouded and diluted.
It's time to take a fresh look at REST. In this talk, Ben Ramsey reintroduces REST and its architectural style. He shows that REST is not only an architecture for web services but that it describes an architecture for the Web. Ramsey will demonstrate how statelessness, a resource-oriented architecture, atomicity of requests, and other traits of REST make the most of the Web's architecture to provide scalable and simpler web services turning the Web into a platform by which rich clients can access and manipulate data.
12. Client-server
Stateless
Cacheable
Layered
Separated, by Hansol Lee
13. RESTful Benefits
Improved response time & reduced
server load
Improves server scalability
Requires less client-side software
Depends less on vendor software
No need for resource discovery
Better long-term compatibility &
evolvability than RPC
Sand Banks Sunset, by Clear Inner Vision
15. RESTful
Practice
Public Domain, from Wikimedia Commons
16. “[REST] 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
Drip Drops and the Spider Web, by Mike Bitzenhofer
17. Hypertext
Transfer
Protocol
URIs provide unique addresses
Constrained interface with methods
and content types
Transactions are atomic
Built-in support for layering
Provides for cache control
#110 Hypertext Transfer Protocol, by maako
18. HTTP Interface
Methods Cut & Paste
GET Copy
PUT Paste Over
POST Paste After
DELETE Cut
#110 Hypertext Transfer Protocol, by maako
19. HTTP Interface
GET
Transfers (copies) a representation of a
resource from server to client
Body must contain enough information
for the client to usefully operate on the
data
Considered safe
Has the property of idempotence
#110 Hypertext Transfer Protocol, by maako
20. HTTP Interface
PUT
Transfers the state from client to the
server (equivalent to paste over)
The body must contain enough
information for the server to operate
on the data
May also create a new resource at the
requested URI
Has the property of idempotence
#110 Hypertext Transfer Protocol, by maako
21. HTTP Interface
POST
Has the same meaning as paste after
May create or update resources,
depending on context
Is not idempotent
#110 Hypertext Transfer Protocol, by maako
22. HTTP Interface
DELETE
Acts like cut
Requests that the resource identified
be destroyed or removed from public
web
Has the property of idempotence
#110 Hypertext Transfer Protocol, by maako
23. Idempotence
Not a sexual dysfunction
The side-effects of N > 0 identical
requests is the same as for a single
request
That is: every time you make the
request, as long as it is an identical
request, exactly the same action
occurs
#110 Hypertext Transfer Protocol, by maako
24. Content Types
HTTP supports content types through
the Content-Type header
A single resource can be transferred in
various content types
Content negotiation used to tell the
server what type to return to the client
REST community doesn’t care for
content negotiation
#110 Hypertext Transfer Protocol, by maako
25. Lifecycle of a Resource
1
POST /content HTTP/1.1
Host: example.org
Content-Type: application/xml
2
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 16:43:56 GMT
Location: /content/1234
#110 Hypertext Transfer Protocol, by maako
26. Lifecycle of a Resource
3
GET /content/1234 HTTP/1.1
Host: example.org
4
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:44:13 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
27. Lifecycle of a Resource
5
PUT /content/1234 HTTP/1.1
Host: example.org
Content-Type: application/xml
6
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:48:26 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
28. Lifecycle of a Resource
7
DELETE /content/1234 HTTP/1.1
Host: example.org
8
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 16:50:47 GMT
#110 Hypertext Transfer Protocol, by maako
29. Resource-oriented
Architecture
1. Represent itself to the client
2. Transition from one state to the next
3. Destroy itself
Additionally, the system knows how to
create a resource.
Where I Teach, by Todd Ehlers
30. Resource-oriented
Architecture
Resources are addressable
Resources have no state
Resources are connected
Resources share the same interface
Where I Teach, by Todd Ehlers
31. Resource-oriented
Architecture
Query string parameters appropriate
in some cases
Pragmatic use of URIs instead of
using HTTP headers
RPC-style APIs are avoided
Representation should have links
URI templates specify URI families
Where I Teach, by Todd Ehlers
32. Resource-oriented
Architecture
Should expose many URIs
Session cookies are not RESTful
Combined resources are RESTful only
if represented as a URI
URIs should facilitate “cut & paste”
Where I Teach, by Todd Ehlers
35. Atom Resource Lifecycle
1
GET /index.atom HTTP/1.1
Host: example.org
2
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:14 GMT
Content-Type: application/atomsvc+xml
Molecule display, by Christian Guthier
36. Atom Resource Lifecycle
3
GET /archives.atom HTTP/1.1
Host: example.org
4
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:46 GMT
Content-Type: application/atom+xml;type=feed
Molecule display, by Christian Guthier
37. Atom Resource Lifecycle
5
GET /categories.atom HTTP/1.1
Host: example.org
6
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:48 GMT
Content-Type: application/atomcat+xml
Molecule display, by Christian Guthier
38. Atom Resource Lifecycle
7
POST /archives.atom HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
8
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 17:16:32 GMT
Location: /archives/1234.atom
Molecule display, by Christian Guthier
39. Atom Resource Lifecycle
9
GET /archives/1234.atom HTTP/1.1
Host: example.org
10
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:16:36 GMT
Content-Type: application/atom+xml;type=entry
Molecule display, by Christian Guthier
40. Atom Resource Lifecycle
11
PUT /archives/1234.atom HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
12
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:23:12 GMT
Content-Type: application/atom+xml;type=entry
Molecule display, by Christian Guthier
41. Atom Resource Lifecycle
13
DELETE /archives/1234.atom HTTP/1.1
Host: example.org
14
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 19:34:29 GMT
Molecule display, by Christian Guthier
42. RESTful
Design
1. Determine your resources
User Content
/users /content
/users/{username} /content/{ID}
Before we had CAD, we had Lead!, by Wendell
43. RESTful
Design
2. Decide the methods for each
resource
/users /users/{username} /content /content/{ID}
GET GET GET GET
POST PUT POST PUT
DELETE DELETE
Before we had CAD, we had Lead!, by Wendell