Upgrade to Pro — share decks privately, control downloads, hide ads and more …

You Look Like You Could Use Some REST! (php|works 2008)

You Look Like You Could Use Some REST! (php|works 2008)

Representational State Transfer, or REST, has become the hip, new buzzword of Web 2.0. But what really makes an application RESTful? Is it pretty URLs? Or the use of XML over HTTP? Is it any web service that doesn't use SOAP? In all of the hype, the definition of REST has become clouded and diluted.

It's time to take a fresh look at REST. In this talk, Ben Ramsey reintroduces REST and its architectural style. He shows that REST is not only an architecture for web services but that it describes an architecture for the Web. Ramsey will demonstrate how statelessness, a resource-oriented architecture, atomicity of requests, and other traits of REST make the most of the Web's architecture to provide scalable and simpler web services turning the Web into a platform by which rich clients can access and manipulate data.

0c217b9a7dd0aa31ed40bd0f453727e1?s=128

Ben Ramsey
PRO

November 13, 2008
Tweet

Transcript

  1. Ben Ramsey ▪ php|works PyWorks ▪ 13 November 2008 You

    Look Like You Could Use Some REST!
  2. REST Roatan Beach - Perfect Day, by Janusz Leszczynski

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

  4. Web Developer Gang Sign, by Josh Lewis How about XML

    over HTTP? #webdevgangsign
  5. A Bar of Ivory Soap, by iirraa Any web service

    that’s not SOAP?
  6. Representational State Transfer Restful Summer, by Clear Inner Vision

  7. Theory of REST Public Domain, from Wikimedia Commons

  8. 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.
  9. Back on the Log Train, by Claire L. Evans Resources

  10. Addressable Address:1304, by Grant Hutchinson

  11. used to interface, by Tom Hensel Uniform Interface

  12. Separated, by Hansol Lee Client-server Stateless Cacheable Layered

  13. 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
  14. A Real-World Analogy Money!, by Tracy Olson

  15. RESTful Practice Public Domain, from Wikimedia Commons

  16. 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
  17. 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
  18. HTTP Interface #110 Hypertext Transfer Protocol, by maako Methods GET

    PUT POST DELETE Cut & Paste Copy Paste Over Paste After Cut
  19. HTTP Interface #110 Hypertext Transfer Protocol, by maako Transfers (copies)

    a representation of a resource from server to client GET Body must contain enough information for the client to usefully operate on the data Considered safe Has the property of idempotence
  20. HTTP Interface #110 Hypertext Transfer Protocol, by maako Transfers the

    state from client to the server (equivalent to paste over) PUT 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
  21. HTTP Interface #110 Hypertext Transfer Protocol, by maako Has the

    same meaning as paste after POST May create or update resources, depending on context Is not idempotent
  22. HTTP Interface #110 Hypertext Transfer Protocol, by maako Acts like

    cut DELETE Requests that the resource identified be destroyed or removed from public web Has the property of idempotence
  23. Idempotence #110 Hypertext Transfer Protocol, by maako 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
  24. 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
  25. #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
  26. #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
  27. #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
  28. #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
  29. 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.
  30. Resource-oriented Architecture Where I Teach, by Todd Ehlers Resources are

    addressable Resources have no state Resources are connected Resources share the same interface
  31. 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
  32. 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”
  33. Atom A resource-oriented protocol for publishing documents that sits on

    top of HTTP Molecule display, by Christian Guthier
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. 9 10 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
  40. 11 12 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
  41. 13 14 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
  42. RESTful Design 1. Determine your resources User Content /users /users/{username}

    /content /content/{ID} Before we had CAD, we had Lead!, by Wendell
  43. RESTful Design 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
  44. RESTful Design 3. Connect your resources Before we had CAD,

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

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

    CAD, we had Lead!, by Wendell
  47. In Conclusion... It’s all about resources. Conclusion, by Mark Cummins

  48. There’s More To Learn Authentication Digital signing Encryption WSDL 2.0

    & WADL
  49. Questions? benramsey.com