Grokking the REST Architectural Style (Dutch PHP 2009)

REST has become the hip, new buzzword of Web 2.0. But what makes an application RESTful? Pretty URLs? XML over HTTP? Any service that's not SOAP? In all the hype, the definition of REST has become clouded and diluted.

Forget what you thought you knew about REST. In this talk, Ben Ramsey reintroduces REST, placing it under a microscope, uncovering each constraint that forms REST's crucial principles. Ramsey explains how REST is a style for network-based software applications, emphasizing scalability and efficiency through separation of concerns and taking advantage of the Web as a platform for rich Internet applications.

Transcript

1. Ben Ramsey ▪ Dutch PHP Conference ▪ 12 June 2009 Grokking the REST Architectural Style
2. Yes. I am this guy.
3. REST Roatan Beach - Perfect Day, by Janusz Leszczynski
4. Tom Coates, by Patrick Lauke Is it about pretty URLs?
5. Web Developer Gang Sign, by Josh Lewis How about XML over HTTP? #webdevgangsign
6. A Bar of Ivory Soap, by iirraa Any web service that’s not SOAP?
7. Representational State Transfer Restful Summer, by Clear Inner Vision
8. Theory of REST Public Domain, from Wikimedia Commons
9. 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.
10. Client-server Separated, by Hansol Lee
11. Stateless Stateless by Koesmanto Bong
12. Cache Cache County, Utah by J. Stephen Conn
13. used to interface, by Tom Hensel Uniform Interface 1.Identification of resources 2.Representation of resources 3.Linked resources 4.Resource metadata
14. Layered Sedimentary Layers by Mark Thurman
15. Code-on-demand jeremy’s tie by Gitchel
16. 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
17. A Real-World Analogy Money!, by Tracy Olson
18. RESTful Practice Public Domain, from Wikimedia Commons
19. 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
20. 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
21. HTTP Interface #110 Hypertext Transfer Protocol, by maako Methods GET PUT POST DELETE Cut & Paste Copy Paste Over Paste After Cut
22. 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
23. #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
24. #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
25. #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
26. #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
27. 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.
28. Resource-oriented Architecture Where I Teach, by Todd Ehlers Resources are addressable Resources have no state Resources are connected Resources share the same interface
29. 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
30. 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”
31. Atom A resource-oriented protocol for publishing documents that sits on top of HTTP Molecule display, by Christian Guthier
32. 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
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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
39. 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
40. Resource-oriented Design 1. Determine your resources User Content /users /users/{username} /content /content/{ID} Before we had CAD, we had Lead!, by Wendell
41. 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
42. 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
43. 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
44. 5. Choose your content type(s) Before we had CAD, we had Lead!, by Wendell Resource-oriented Design
45. In conclusion... Conclusion, by Mark Cummins
46. Questions? benramsey.com
47. 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.