Search

Grokking the REST Architectural Style

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1





    Is REST about so-called “pretty” URLs?

    Tom Coates, who apparently made this statement at a “Future of Web Apps” summit.

    If you want to be real cool, take a pic of yourself doing this and post it to Flickr with the tag “webdevgangsign.”

    Or not RPC (remote procedure call)?

    * Representational State Transfer

    * Term originated in 2000 in Roy Fielding’s doctoral dissertation about the Web entitled “Architectural Styles and the Design of Network-based Software Architectures”

    * Not an architecture or a standard for developing web services

    * Not a particular format or pattern

    * It is a set of design principles


    There are six major constraints that define the REST architectural style.

    There are six major constraints that define the REST architectural style.

    There are six major constraints that define the REST architectural style.

    There are six major constraints that define the REST architectural style.

    The client-server relationship provides for a separation of concerns. This separation is very important to REST. IMO, it’s perhaps the most important constraint. We’re all-too-familiar with the client-server relationship, since it’s how the Web works, but it’s also what makes the other REST constraints possible and beneficial.



    What is a resource?

    From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”

    All resources share a uniform interface for the transfer of state between client and resource, consisting of

    - A constrained set of well-defined operations
    - A constrained set of content types, optionally supporting code on demand

    What is a resource?

    From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”

    All resources share a uniform interface for the transfer of state between client and resource, consisting of

    - A constrained set of well-defined operations
    - A constrained set of content types, optionally supporting code on demand

    What is a resource?

    From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”

    All resources share a uniform interface for the transfer of state between client and resource, consisting of

    - A constrained set of well-defined operations
    - A constrained set of content types, optionally supporting code on demand

    What is a resource?

    From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”

    All resources share a uniform interface for the transfer of state between client and resource, consisting of

    - A constrained set of well-defined operations
    - A constrained set of content types, optionally supporting code on demand



    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Advocates claim that REST:

    * Provides improved response time and reduced server load due to its support for the caching of representations
    * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
    * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
    * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
    * Provides equivalent functionality when compared to alternative approaches to communication
    * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
    * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

    One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable

    Humans live in the world of representations. Representation, as a concept, is an attempt (arguably futile) to reach certain acceptable level of objectivity.

    For example, if a person wants to buy a house, that person needs to qualify for a mortgage. If that person explains to the mortgage broker that he has $50,000.00 cash available for the down payment toward purchasing the house, the broker will not go ahead and approve the mortgage, even though the quoted amount would be fully satisfactory. What the mortgage broker needs is a more objective argument that would reassure the issuer that the party asking for the mortgage does indeed have enough money for the down payment.

    But how is the issuer to go about obtaining the more objective proof? Certainly not by going directly into the applicant's safety vault and counting the money deposited there. Instead, the issuer is simply expecting to receive a representation of that person's balance in his bank account.

    That representation projects a sufficient illusion of objectivity, so that the involved parties could sufficiently relax and that the business transaction can eventually take place.

    In the same manner, any transaction that transpires on the web is based on the similar representational logic. The actual resource is never being touched. Instead, various representations of the said resource are being prepared, rendered, and shipped to the clients for consumption. Same as in the real world, where the mortgage issuer will never actually touch client's money, but will instead be satisfied with a mere piece of paper representing the balance, resources on the web never get to be directly manipulated by the clients.




    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering

    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering

    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering

    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering

    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering

    URIs uniquely address resources

    HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface

    All transactions are atomic

    HTTP provides cache control

    HTTP provides layering










    13 Favorites

    Grokking the REST Architectural Style - Presentation Transcript

    1. Grokking the REST Architectural Style Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009
    2. Yes. I am this guy.
    3. Roatan Beach - Perfect Day, by Janusz Leszczynski REST
    4. Is it about pretty URLs? Tom Coates, by Patrick Lauke
    5. #webdevgangsign How about XML over HTTP? Web Developer Gang Sign, by Josh Lewis
    6. Any web service that’s not SOAP? A Bar of Ivory Soap, by iirraa
    7. Representational State Transfer Restful Summer, by Clear Inner Vision
    8. Public Domain, from Wikimedia Commons Theory of REST
    9. 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. 1.Identification of resources 2.Representation of resources 3.Linked resources 4.Resource metadata Uniform Interface used to interface, by Tom Hensel
    14. Layered Sedimentary Layers by Mark Thurman
    15. jeremyʼs tie by Gitchel Code-on-demand
    16. 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
    17. A Real-World Analogy Money!, by Tracy Olson
    18. RESTful Practice Public Domain, from Wikimedia Commons
    19. “[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
    20. 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
    21. HTTP Interface Methods Cut & Paste GET Copy PUT Paste Over POST Paste After DELETE Cut #110 Hypertext Transfer Protocol, by maako
    22. 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
    23. 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
    24. 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
    25. 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
    26. 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
    27. 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
    28. Resource-oriented Architecture Resources are addressable Resources have no state Resources are connected Resources share the same interface Where I Teach, by Todd Ehlers
    29. 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
    30. 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
    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 Feed (Collection) Document application/atom+xml;type=feed Category Document application/atomcat+xml Service Document application/atomsvc+xml Molecule display, by Christian Guthier
    33. 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
    34. 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
    35. 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
    36. 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
    37. 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
    38. 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
    39. 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
    40. Resource-oriented Design 1. Determine your resources User Content /users /content /users/{username} /content/{ID} Before we had CAD, we had Lead!, by Wendell
    41. Resource-oriented Design 2. Decide the methods for each resource /users /users/{username} /content /content/{ID} GET GET GET GET POST PUT POST PUT DELETE DELETE Before we had CAD, we had Lead!, by Wendell
    42. 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
    43. Resource-oriented Design 4. Determine your data schemas User Content id id username owner firstname title lastname file/content Before we had CAD, we had Lead!, by Wendell
    44. Resource-oriented Design 5. Choose your content type(s) Before we had CAD, we had Lead!, by Wendell
    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.

    + Ben RamseyBen Ramsey, 5 months ago

    custom

    2670 views, 13 favs, 4 embeds more stats

    REST has become the hip, new buzzword of Web 2.0. B more

    More info about this document

    CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

    Go to text version

    • Total Views 2670
      • 2358 on SlideShare
      • 312 from embeds
    • Comments 0
    • Favorites 13
    • Downloads 94
    Most viewed embeds
    • 296 views on http://techportal.ibuildings.com
    • 13 views on http://kmoonki.tistory.com
    • 2 views on http://feeds2.feedburner.com
    • 1 views on http://feeds.feedburner.com

    more

    All embeds
    • 296 views on http://techportal.ibuildings.com
    • 13 views on http://kmoonki.tistory.com
    • 2 views on http://feeds2.feedburner.com
    • 1 views on http://feeds.feedburner.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    more
    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved