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

Code-on-demand
jeremyʼs tie by Gitchel

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 PUT POST DELETE

Copy Paste Over Paste After 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
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

Resource-oriented Design
1. Determine your resources
User
/users /users/{username}

Content
/content /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 POST GET PUT DELETE GET POST GET PUT 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
id username firstname lastname

Content
id owner title 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.

Sign up to vote on this title
UsefulNot useful