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.

Transcript

1. Ben Ramsey ■ php|works PyWorks ■ 13 November 2008
   You Look Like You
   Could Use Some REST!
   

   View Slide

2. REST
   Roatan Beach - Perfect Day, by Janusz Leszczynski
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. Representational
   State Transfer
   Restful Summer, by Clear Inner Vision
   

   View Slide

7. Theory
   of REST
   Public Domain, from Wikimedia Commons
   

   View Slide

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.
   

   View Slide

9. Back on the Log Train, by Claire L. Evans
   Resources
   

   View Slide

10. Addressable
    Address:1304, by Grant Hutchinson
    

    View Slide

11. used to interface, by Tom Hensel
    Uniform
    Interface
    

    View Slide

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

    View Slide

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
    

    View Slide

14. A Real-World
    Analogy
    Money!, by Tracy Olson
    

    View Slide

15. RESTful
    Practice
    Public Domain, from Wikimedia Commons
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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”
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

44. RESTful
    Design
    3. Connect your resources
    Before we had CAD, we had Lead!, by Wendell
    

    View Slide

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

    View Slide

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

    View Slide

47. In Conclusion...
    It’s all about resources.
    Conclusion, by Mark Cummins
    

    View Slide

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

    View Slide

49. Questions?
    benramsey.com
    

    View Slide