Your SlideShare is downloading. ×
You Look Like You Could Use Some REST!
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

You Look Like You Could Use Some REST!

3,895

Published on

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 …

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.

Published in: Technology
2 Comments
4 Likes
Statistics
Notes
  • The usage of imagery in this display is really efficient. You have done a fantastic job here friend.
    Sharika
    http://winkhealth.com http://financewink.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Blogged here: http://benramsey.com/archives/works08/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
3,895
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
72
Comments
2
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. You Look Like You Could Use Some REST! Ben Ramsey ■ php|works PyWorks ■ 13 November 2008
  • 2. Roatan Beach - Perfect Day, by Janusz Leszczynski REST
  • 3. Is it about pretty URLs? Tom Coates, by Patrick Lauke
  • 4. #webdevgangsign How about XML over HTTP? Web Developer Gang Sign, by Josh Lewis
  • 5. Any web service that’s not SOAP? A Bar of Ivory Soap, by iirraa
  • 6. Representational State TransferRestful Summer, by Clear Inner Vision
  • 7. Public Domain, from Wikimedia Commons Theory of REST
  • 8. REST defines a style by which a resource’s state may be transferred using a representation of that resource.
  • 9. Resources Back on the Log Train, by Claire L. Evans
  • 10. Addressable Address:1304, by Grant Hutchinson
  • 11. Uniform Interface used to interface, by Tom Hensel
  • 12. Client-server Stateless Cacheable Layered Separated, by Hansol Lee
  • 13. 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
  • 14. A Real-World Analogy Money!, by Tracy Olson
  • 15. RESTful Practice Public Domain, from Wikimedia Commons
  • 16. “[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
  • 17. 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
  • 18. HTTP Interface Methods Cut & Paste GET Copy PUT Paste Over POST Paste After DELETE Cut #110 Hypertext Transfer Protocol, by maako
  • 19. HTTP Interface GET Transfers (copies) a representation of a resource from server to client Body must contain enough information for the client to usefully operate on the data Considered safe Has the property of idempotence #110 Hypertext Transfer Protocol, by maako
  • 20. HTTP Interface PUT Transfers the state from client to the server (equivalent to paste over) 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 #110 Hypertext Transfer Protocol, by maako
  • 21. HTTP Interface POST Has the same meaning as paste after May create or update resources, depending on context Is not idempotent #110 Hypertext Transfer Protocol, by maako
  • 22. HTTP Interface DELETE Acts like cut Requests that the resource identified be destroyed or removed from public web Has the property of idempotence #110 Hypertext Transfer Protocol, by maako
  • 23. Idempotence 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 #110 Hypertext Transfer Protocol, by maako
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Resource-oriented Architecture Resources are addressable Resources have no state Resources are connected Resources share the same interface Where I Teach, by Todd Ehlers
  • 31. 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
  • 32. 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
  • 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 Feed (Collection) Document application/atom+xml;type=feed Category Document application/atomcat+xml Service Document application/atomsvc+xml Molecule display, by Christian Guthier
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. RESTful Design 1. Determine your resources User Content /users /content /users/{username} /content/{ID} Before we had CAD, we had Lead!, by Wendell
  • 43. RESTful 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
  • 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

×