Grokking the
REST Architectural Style
Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009
Yes.
I am this guy.
Roatan Beach - Perfect Day, by Janusz Leszczynski
REST
Is it about
pretty URLs?
Tom Coates, by Patrick Lauke
#webdevgangsign
How about XML
over HTTP? Web Developer Gang Sign, by Josh Lewis
Any web service that’s
not SOAP?
A Bar of Ivory Soap, by iirraa
Representational
State Transfer Restful Summer, by Clear Inner Vision
Public Domain, from Wikimedia Commons
Theory
of REST
REST defines a style by
which a resource’s state
may be transferred using a
representation of that
resource.
Client-server
Separated, by Hansol Lee
Stateless
Stateless by Koesmanto Bong
Cache
Cache County, Utah by J. Stephen Conn
[Link] of resources
[Link] of resources
[Link] resources
[Link] metadata
Uniform
Interface
used to interface, by Tom Hensel
Layered
Sedimentary Layers by Mark Thurman
jeremyʼs tie by Gitchel
Code-on-demand
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
A Real-World
Analogy
Money!, by Tracy Olson
RESTful
Practice
Public Domain, from Wikimedia Commons
“[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
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
HTTP Interface
Methods Cut & Paste
GET Copy
PUT Paste Over
POST Paste After
DELETE Cut
#110 Hypertext Transfer Protocol, by maako
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
Lifecycle of a Resource
1
POST /content HTTP/1.1
Host: [Link]
Content-Type: application/xml
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 16:43:56 GMT
Location: /content/1234
#110 Hypertext Transfer Protocol, by maako
Lifecycle of a Resource
3
GET /content/1234 HTTP/1.1
Host: [Link]
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:44:13 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
Lifecycle of a Resource
5
PUT /content/1234 HTTP/1.1
Host: [Link]
Content-Type: application/xml
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:48:26 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
Lifecycle of a Resource
7
DELETE /content/1234 HTTP/1.1
Host: [Link]
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 16:50:47 GMT
#110 Hypertext Transfer Protocol, by maako
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
Resource-oriented
Architecture
Resources are addressable
Resources have no state
Resources are connected
Resources share the same interface
Where I Teach, by Todd Ehlers
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
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
Atom
A resource-oriented protocol for
publishing documents that sits on top of
HTTP
Molecule display, by Christian Guthier
Atom
Entry Document
application/atom+xml;type=entry
Feed (Collection) Document
application/atom+xml;type=feed
Category Document
application/atomcat+xml
Service Document
application/atomsvc+xml
Molecule display, by Christian Guthier
Atom Resource Lifecycle
1
GET /[Link] HTTP/1.1
Host: [Link]
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:14 GMT
Content-Type: application/atomsvc+xml
Molecule display, by Christian Guthier
Atom Resource Lifecycle
3
GET /[Link] HTTP/1.1
Host: [Link]
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
Atom Resource Lifecycle
5
GET /[Link] HTTP/1.1
Host: [Link]
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:48 GMT
Content-Type: application/atomcat+xml
Molecule display, by Christian Guthier
Atom Resource Lifecycle
7
POST /[Link] HTTP/1.1
Host: [Link]
Content-Type: application/atom+xml;type=entry
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 17:16:32 GMT
Location: /archives/[Link]
Molecule display, by Christian Guthier
Atom Resource Lifecycle
9
GET /archives/[Link] HTTP/1.1
Host: [Link]
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
Atom Resource Lifecycle
11
PUT /archives/[Link] HTTP/1.1
Host: [Link]
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
Atom Resource Lifecycle
13
DELETE /archives/[Link] HTTP/1.1
Host: [Link]
14
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 19:34:29 GMT
Molecule display, by Christian Guthier
Resource-oriented
Design
1. Determine your resources
User Content
/users /content
/users/{username} /content/{ID}
Before we had CAD, we had Lead!, by Wendell
Resource-oriented
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
Resource-oriented
Design
3. Link your resources
Users own content
Each user owns multiple content items
Each content item has one owner
Before we had CAD, we had Lead!, by Wendell
Resource-oriented
Design
4. Determine your data schemas
User Content
id id
username owner
firstname title
lastname file/content
Before we had CAD, we had Lead!, by Wendell
Resource-oriented
Design
5. Choose your content type(s)
Before we had CAD, we had Lead!, by Wendell
In conclusion...
Conclusion, by Mark Cummins
Questions?
[Link]
Grokking the REST Architectural Style
Copyright © Ben Ramsey. Some rights reserved.
This work is licensed under a Creative Commons
Attribution-Noncommercial-No Derivative Works 3.0 United
States License.
For uses not covered under this license, please contact the
author.
