You Look Like You
Could Use Some REST!
Ben Ramsey ■ php|works PyWorks ■ 13 November 2008

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 TransferRestful 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.

Resources
Back on the Log Train, by Claire L. Evans

Addressable
Address:1304, by Grant Hutchinson

Uniform
Interface
used to interface, by Tom Hensel

Client-server
Stateless
Cacheable
Layered
Separated, by Hansol Lee

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

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

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

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

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

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

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
2
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
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

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

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

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
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

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

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

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

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

RESTful
Design
1. Determine your resources
User Content
/users /content
/users/{username} /content/{ID}
Before we had CAD, we had Lead!, by Wendell

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

RESTful
Design
3. Connect your resources
Before we had CAD, we had Lead!, by Wendell

RESTful
Design
4. Determine your data schemas
Before we had CAD, we had Lead!, by Wendell

RESTful
Design
5. Choose your content type(s)
Before we had CAD, we had Lead!, by Wendell

In Conclusion...
It’s all about resources.
Conclusion, by Mark Cummins

There’s More To Learn
Authentication
Digital signing
Encryption
WSDL 2.0 & WADL

Questions?
benramsey.com