RESTful Web Services

1,249 views
1,187 views

Published on

An updated version of my RESTful Web Services talk.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,249
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

RESTful Web Services

  1. 1. What Are Web Services?
  2. 2. “The Machine-Readable Web”
  3. 3. Two Styles of Web Service
  4. 4. Service-Oriented Architecture SOAP, XML-RPC, etc.
  5. 5. Resource-Oriented Architecture REST
  6. 6. “The Human-Readable Web”
  7. 7. URLs
  8. 8. HTTP
  9. 9. HTML
  10. 10. URLs + HTTP + HTML
  11. 11. URI + HTTP + HTML
  12. 12. URI + HTTP + Links
  13. 13. URI + HTTP + Hypermedia
  14. 14. Fundamental Web Technologies
  15. 15. REST means using fundamental webtechnologies idiomatically as the basis for designing web services.
  16. 16. Why use REST?
  17. 17. The Web Was Designed For It
  18. 18. The Web Was Designed For It (Sort of.)
  19. 19. Appeal to AuthorityAn appeal to authority or argument by authority is a type of argumentin logic consisting on basing the truth value of an assertion on theauthority, knowledge, expertise, or position of the person asserting it. –Wikipedia
  20. 20. Roy T. Fielding, Ph.D.• Co-founder, chairman of the Apache Software Foundation• Co-founder of the Apache HTTP Project• On IETF working groups for HTTP, URI, and HTML • Architectural principal on HTTP working group • First name on HTTP spec• Originator of REST
  21. 21. Sam Ruby• Board member of the Apache Software Foundation• Co-chair of W3C’s HTML Working Group• Co-creator of the Web Feed Validator• Originator of Atom• Secretary of the IETF’s AtomPub working group• Co-author of “RESTful Web Services”
  22. 22. Greg Hines• Currently giving a presentation about REST
  23. 23. Fielding developed RESTwhile writing HTTP 1.1…
  24. 24. Fielding developed RESTwhile writing HTTP 1.1… What have you done lately?
  25. 25. Aspects of a RESTful Web Service
  26. 26. Resources
  27. 27. ResourcesA resource can be practically anything.• A blog post• A collection of blog posts• An image• A user• Map coordinates• A bank transaction• Search results
  28. 28. Representations
  29. 29. A Kitten
  30. 30. Some TextName: BobBreed: TabbyFur Length: MediumFur Color: Gray, Brown, WhiteAge: 8 monthsPersonality: Outgoing, but loves to cuddle.
  31. 31. A Picture
  32. 32. A Drawing
  33. 33. A HaikuMy cat is named Bob.I named him after Bob. Bob’sbreath smells like cat food.
  34. 34. A Blog Post
  35. 35. HTML<!DOCTYPE html><html lang="en"> <head> <title>Gregs Blog: My First Blog Post</title> </head> <body> <article> <header> <h1>My First Blog Post</h1> <p>By Greg Hines</p> </header> <p>This is my first blog post. Woo.</p> <footer> <p>Posted on February 2, 2012 at 12:18 PM</p> <ul class="tags"> <li><a href="/tags/awesome">awesome</a></li> </ul> <p><a href="/entries/2012/02/my-first-blog-post">permalink</a></p> </footer> </article> </body></html>
  36. 36. JSON{ "uri": "/entries/2012/02/my-first-blog-post", "title": "My First Blog Post", "author": "/users/greg", "created": 1328728680, "content": "This is my first blog post. Woo.", "tags": [ "/tags/awesome" ]}
  37. 37. Addressability
  38. 38. AddressabilityEvery resource has at least one URI; every URI points to a resource.http://example.com/entries/2012/02/restful-web-serviceshttp://example.com/tags/awesomehttp://example.com/
  39. 39. Interface Uniformity
  40. 40. Interface UniformityGET POST
  41. 41. Interface Uniformity GET POST PUT DELETE
  42. 42. Interface Uniformity GET POST PUTDELETE HEAD OPTIONS
  43. 43. Interface Uniformity GET POST PUTDELETE HEAD OPTIONS TRACE CONNECT
  44. 44. Interface Uniformity GET POST PUTDELETE HEAD OPTIONS
  45. 45. Interface Uniformity GET POST PUTDELETE HEAD OPTIONS PATCH
  46. 46. Idempotency
  47. 47. Being able to perform an operationmultiple times without changing the result after the initial operation.
  48. 48. Interface Uniformity GET POST PUTDELETE HEAD OPTIONS
  49. 49. Status Codes
  50. 50. Connectedness
  51. 51. Resources Link to Each Other
  52. 52. Connectedness<?xml version="1.0" encoding="UTF-8"?><resource xmlns="http://example.com/ns/resource"> <content>...</content> <nextResource href="http://example.com/resource/3"/> <prevResource href="http://example.com/resource/1"/></resource>
  53. 53. Connectedness<?xml version="1.0" encoding="UTF-8"?><resource xmlns="http://example.com/ns/resource"> <content>...</content> <nextResource href="http://example.com/resource/3"/> <prevResource href="http://example.com/resource/1"/></resource><link rel="alternate" type="application/atom+xml" href="http://example.com/resource/2.atom" />
  54. 54. HATEOAS
  55. 55. Statelessness
  56. 56. HTTP Is Stateless
  57. 57. Every RequestHappens in Isolation
  58. 58. State Machine
  59. 59. Resource State Server-Side
  60. 60. Application State Client-Side
  61. 61. Transferring State
  62. 62. Every HTTP request transfersstate between the application and the requested resource.
  63. 63. Resource  Application e.g. GET
  64. 64. Resource  Application e.g. PUT
  65. 65. Representation State Transfer
  66. 66. Representation State Transfer I see what you did there…
  67. 67. Richardson Maturity Model
  68. 68. Plain Old XML Level Zero
  69. 69. Resources Level One
  70. 70. HTTP Verbs Level Two
  71. 71. Hypermedia Level Three
  72. 72. Strive for Level Three
  73. 73. Be OK with Level Two
  74. 74. Be Embarrassed by Level One
  75. 75. Die in a Fire for Level Zero

×