Grokking the REST Architectural Style (Dutch PHP 2009)

Embed

Start on current slide

Slide 1

Slide 1 text

Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009 Grokking the REST Architectural Style

Slide 2

Slide 2 text

Yes. I am this guy.

Slide 3

Slide 3 text

REST Roatan Beach - Perfect Day, by Janusz Leszczynski

Slide 4

Slide 4 text

Tom Coates, by Patrick Lauke Is it about pretty URLs?

Slide 5

Slide 5 text

Web Developer Gang Sign, by Josh Lewis How about XML over HTTP? #webdevgangsign

Slide 6

Slide 6 text

A Bar of Ivory Soap, by iirraa Any web service that’s not SOAP?

Slide 7

Slide 7 text

Representational State Transfer Restful Summer, by Clear Inner Vision

Slide 8

Slide 8 text

Theory of REST Public Domain, from Wikimedia Commons

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

Client-server Separated, by Hansol Lee

Slide 11

Slide 11 text

Stateless Stateless by Koesmanto Bong

Slide 12

Slide 12 text

Cache Cache County, Utah by J. Stephen Conn

Slide 13

Slide 13 text

used to interface, by Tom Hensel Uniform Interface 1.Identiﬁcation of resources 2.Representation of resources 3.Linked resources 4.Resource metadata

Slide 14

Slide 14 text

Layered Sedimentary Layers by Mark Thurman

Slide 15

Slide 15 text

Code-on-demand jeremy’s tie by Gitchel

Slide 16

Slide 16 text

Sand Banks Sunset, by Clear Inner Vision RESTful Beneﬁts 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

Slide 17

Slide 17 text

A Real-World Analogy Money!, by Tracy Olson

Slide 18

Slide 18 text

RESTful Practice Public Domain, from Wikimedia Commons

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

HTTP Interface #110 Hypertext Transfer Protocol, by maako Methods GET PUT POST DELETE Cut & Paste Copy Paste Over Paste After Cut

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

#110 Hypertext Transfer Protocol, by maako 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 Lifecycle of a Resource

Slide 24

Slide 24 text

#110 Hypertext Transfer Protocol, by maako 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 Lifecycle of a Resource

Slide 25

Slide 25 text

#110 Hypertext Transfer Protocol, by maako 5 PUT /content/1234 HTTP/1.1 Host: example.org Content-Type: application/xml Lifecycle of a Resource 6 HTTP/1.x 200 OK Date: Thu, 13 November 2008 16:48:26 GMT Content-Type: application/xml

Slide 26

Slide 26 text

#110 Hypertext Transfer Protocol, by maako 7 DELETE /content/1234 HTTP/1.1 Host: example.org Lifecycle of a Resource 8 HTTP/1.x 204 No Content Date: Thu, 13 November 2008 16:50:47 GMT

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

Resource-oriented Architecture Where I Teach, by Todd Ehlers Resources are addressable Resources have no state Resources are connected Resources share the same interface

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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”

Slide 31

Slide 31 text

Atom A resource-oriented protocol for publishing documents that sits on top of HTTP Molecule display, by Christian Guthier

Slide 32

Slide 32 text

Atom Entry Document application/atom+xml;type=entry Molecule display, by Christian Guthier Feed (Collection) Document application/atom+xml;type=feed Category Document application/atomcat+xml Service Document application/atomsvc+xml

Slide 33

Slide 33 text

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 Atom Resource Lifecycle Molecule display, by Christian Guthier

Slide 34

Slide 34 text

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 Atom Resource Lifecycle Molecule display, by Christian Guthier

Slide 35

Slide 35 text

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 Atom Resource Lifecycle Molecule display, by Christian Guthier

Slide 36

Slide 36 text

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 Atom Resource Lifecycle Molecule display, by Christian Guthier

Slide 37

Slide 37 text

9 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:16:36 GMT Content-Type: application/atom+xml;type=entry Atom Resource Lifecycle GET /archives/1234.atom HTTP/1.1 Host: example.org Molecule display, by Christian Guthier

Slide 38

Slide 38 text

HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:23:12 GMT Content-Type: application/atom+xml;type=entry Atom Resource Lifecycle PUT /archives/1234.atom HTTP/1.1 Host: example.org Content-Type: application/atom+xml;type=entry Molecule display, by Christian Guthier

Slide 39

Slide 39 text

HTTP/1.x 204 No Content Date: Thu, 13 November 2008 19:34:29 GMT Atom Resource Lifecycle DELETE /archives/1234.atom HTTP/1.1 Host: example.org Molecule display, by Christian Guthier

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

2. Decide the methods for each resource /users GET POST /content GET POST /users/{username} GET PUT DELETE /content/{ID} GET PUT DELETE Before we had CAD, we had Lead!, by Wendell Resource-oriented Design

Slide 42

Slide 42 text

3. Link your resources Before we had CAD, we had Lead!, by Wendell Resource-oriented Design Users own content Each user owns multiple content items Each content item has one owner

Slide 43

Slide 43 text

4. Determine your data schemas Before we had CAD, we had Lead!, by Wendell User Content id username firstname lastname id owner title file/content Resource-oriented Design

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

In conclusion... Conclusion, by Mark Cummins

Slide 46

Slide 46 text

Questions? benramsey.com

Slide 47

Slide 47 text

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.