Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009

Grokking theREST Architectural Style

Yes.

I am this guy.

REST

Roatan Beach - Perfect Day, by Janusz Leszczynski

Tom Coates, by Patrick Lauke

Is it about pretty URLs?

Web Developer Gang Sign, by Josh Lewis

How about XML over HTTP?

#webdevgangsign

A Bar of Ivory Soap, by iirraa

Any web service that’s not SOAP?

RepresentationalState Transfer

Restful Summer, by Clear Inner Vision

Theoryof REST

Public Domain, from Wikimedia Commons

REST defines a style by which a resource’s state may be transferred using a representation of that resource.

REST defines a style by which a resource’s state may be transferred using a representation of that resource.

REST defines a style by which a resource’s state may be transferred using a representation of that resource.

Client-serverSeparated, by Hansol Lee

Stateless

Stateless by Koesmanto Bong

Cache

Cache County, Utah by J. Stephen Conn

used to interface, by Tom Hensel

Uniform Interface

1.Identification of resources2.Representation of resources3.Linked resources4.Resource metadata

Layered

Sedimentary Layers by Mark Thurman

Code-on-demandjeremyʼs tie by Gitchel

Sand Banks Sunset, by Clear Inner Vision

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

A Real-World Analogy

Money!, by Tracy Olson

RESTfulPractice

Public Domain, from Wikimedia Commons

Drip Drops and the Spider Web, by Mike Bitzenhofer

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

Hypertext Transfer Protocol

#110 Hypertext Transfer Protocol, by maako

URIs provide unique addresses

Constrained interface with methods and content types

Transactions are atomic

Built-in support for layering

Provides for cache control

HTTP Interface

#110 Hypertext Transfer Protocol, by maako

Methods

GETPUTPOSTDELETE

Cut & Paste

CopyPaste OverPaste AfterCut

Content Types

#110 Hypertext Transfer Protocol, by maako

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

1

POST /content HTTP/1.1Host: example.orgContent-Type: application/xml

2

HTTP/1.x 201 CreatedDate: Thu, 13 November 2008 16:43:56 GMTLocation: /content/1234

Lifecycle of a Resource

#110 Hypertext Transfer Protocol, by maako

3

GET /content/1234 HTTP/1.1Host: example.org

4

HTTP/1.x 200 OKDate: Thu, 13 November 2008 16:44:13 GMTContent-Type: application/xml

Lifecycle of a Resource

#110 Hypertext Transfer Protocol, by maako

5

PUT /content/1234 HTTP/1.1Host: example.orgContent-Type: application/xml

Lifecycle of a Resource

6

HTTP/1.x 200 OKDate: Thu, 13 November 2008 16:48:26 GMTContent-Type: application/xml

#110 Hypertext Transfer Protocol, by maako

7

DELETE /content/1234 HTTP/1.1Host: example.org

Lifecycle of a Resource

8

HTTP/1.x 204 No ContentDate: Thu, 13 November 2008 16:50:47 GMT

Resource-oriented Architecture

Where I Teach, by Todd Ehlers

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.

Resource-oriented Architecture

Where I Teach, by Todd Ehlers

Resources are addressable

Resources have no state

Resources are connected

Resources share the same interface

Resource-oriented Architecture

Where I Teach, by Todd Ehlers

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

Resource-oriented Architecture

Where I Teach, by Todd Ehlers

Should expose many URIs

Session cookies are not RESTful

Combined resources are RESTful only if represented as a URI

URIs should facilitate “cut & paste”

Atom

A resource-oriented protocol for publishing documents that sits on top of HTTP

Molecule display, by Christian Guthier

Atom

Entry Documentapplication/atom+xml;type=entry

Molecule display, by Christian Guthier

Feed (Collection) Documentapplication/atom+xml;type=feed

Category Documentapplication/atomcat+xml

Service Documentapplication/atomsvc+xml

1

GET /index.atom HTTP/1.1Host: example.org

2

HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:14 GMTContent-Type: application/atomsvc+xml

Atom Resource Lifecycle

Molecule display, by Christian Guthier

3

GET /archives.atom HTTP/1.1Host: example.org

4

HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:46 GMTContent-Type: application/atom+xml;type=feed

Atom Resource Lifecycle

Molecule display, by Christian Guthier

5

GET /categories.atom HTTP/1.1Host: example.org

6

HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:48 GMTContent-Type: application/atomcat+xml

Atom Resource Lifecycle

Molecule display, by Christian Guthier

7

POST /archives.atom HTTP/1.1Host: example.orgContent-Type: application/atom+xml;type=entry

8

HTTP/1.x 201 CreatedDate: Thu, 13 November 2008 17:16:32 GMTLocation: /archives/1234.atom

Atom Resource Lifecycle

Molecule display, by Christian Guthier

9

10

HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:16:36 GMTContent-Type: application/atom+xml;type=entry

Atom Resource Lifecycle

GET /archives/1234.atom HTTP/1.1Host: example.org

Molecule display, by Christian Guthier

11

12

HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:23:12 GMTContent-Type: application/atom+xml;type=entry

Atom Resource Lifecycle

PUT /archives/1234.atom HTTP/1.1Host: example.orgContent-Type: application/atom+xml;type=entry

Molecule display, by Christian Guthier

13

14

HTTP/1.x 204 No ContentDate: Thu, 13 November 2008 19:34:29 GMT

Atom Resource Lifecycle

DELETE /archives/1234.atom HTTP/1.1Host: example.org

Molecule display, by Christian Guthier

Resource-orientedDesign

1. Determine your resources

User Content

/users/users/{username}

/content/content/{ID}

Before we had CAD, we had Lead!, by Wendell

2. Decide the methods for each resource

/users

GETPOST

/content

GETPOST

/users/{username}

GETPUTDELETE

/content/{ID}

GETPUTDELETE

Before we had CAD, we had Lead!, by Wendell

Resource-orientedDesign

3. Link your resources

Before we had CAD, we had Lead!, by Wendell

Resource-orientedDesign

Users own content

Each user owns multiple content items

Each content item has one owner

4. Determine your data schemas

Before we had CAD, we had Lead!, by Wendell

User Content

idusernamefirstnamelastname

idownertitlefile/content

Resource-orientedDesign

5. Choose your content type(s)

Before we had CAD, we had Lead!, by Wendell

Resource-orientedDesign

In conclusion...

Conclusion, by Mark Cummins

Questions?

benramsey.com

Grokking the REST Architectural StyleCopyright © 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.