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

1.Identification of resources
2.Representation of resources
3.Linked resources
4.Resource 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: example.org
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: example.org

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: example.org
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: example.org

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 /index.atom HTTP/1.1

Host: example.org

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 /archives.atom HTTP/1.1

Host: example.org

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 /categories.atom HTTP/1.1

Host: example.org

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 /archives.atom HTTP/1.1

Host: example.org
Content-Type: application/atom+xml;type=entry

HTTP/1.x 201 Created

Date: Thu, 13 November 2008 17:16:32 GMT
Location: /archives/1234.atom

Molecule display, by Christian Guthier

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

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

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

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?

benramsey.com
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.