Successfully reported this slideshow.

RESTful Web Services



Loading in …3
1 of 49
1 of 49

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

RESTful Web Services

  1. 1. Smart IT Engineering Ltd. RESTful Web Services Imran M Yousuf Smart IT Engineering Ltd.
  2. 2. Smart IT Engineering Ltd. What's not covered <ul><li>Comparison between various Web Service technologies
  3. 3. Hands on tutorial on how code a RESTful WS
  4. 4. Details of how HTTP works
  5. 5. Details on various media formats </li></ul>
  6. 6. Smart IT Engineering Ltd. What to expect <ul><li>REST </li><ul><li>Definition
  7. 7. Discussion on its constraints
  8. 8. WWW </li></ul><li>RESTful Web Service </li><ul><li>Resource Oriented Architecture (ROA)
  9. 9. Constraints of ROA
  10. 10. Examples </li></ul></ul>
  11. 11. Smart IT Engineering Ltd. What to expect <ul><li>A Design Case Study
  12. 12. Questions </li></ul>
  13. 13. Smart IT Engineering Ltd. What is REST <ul><li>RE presentational S tate T ransfer
  14. 14. Proposed by Dr. Roy Thomas Fielding in his PhD dissertation titled - “Architectural Styles and the Design of Network-based Software Architectures” </li></ul>
  15. 15. Smart IT Engineering Ltd. What is REST <ul><li>RE presentational S tate T ransfer
  16. 16. REST is an architectural style composed of specific constraints.
  17. 17. The Constraints - </li></ul>- Client-Server - Stateless - Cache - Uniform Interface - Layered System - Code-On-Demand (Optional)
  18. 18. Smart IT Engineering Ltd. REST Constraints <ul>Client-Server <li>No restrictions on the nature of the client
  19. 19. No restrictions on the number of the clients
  20. 20. No restriction on communication medium / protocol </li></ul>Client (Browser) Client (CLI – curl, wget) Client (Desktop) Network Client (Mobile) Client (Another System)
  21. 21. Smart IT Engineering Ltd. REST Constraints <ul>Client-Server <li>Separate data storage concerns
  22. 22. Improve user interface portability across multiple platforms
  23. 23. Improve scalability by simplifying server components
  24. 24. Components evolve independently </li></ul>
  25. 25. Smart IT Engineering Ltd. REST Constraints <ul>Stateless “ ... each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.” </ul>Advantages Visibility Reliability Scalability
  26. 26. Smart IT Engineering Ltd. REST Constraints <ul>Cache “ ... the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.” </ul>Advantages Efficient Scalability Performance
  27. 27. Smart IT Engineering Ltd. REST Constraints <ul>Layered System The layered system style or also popularly referred to as n-layer system allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot &quot;see&quot; beyond the immediate layer with which they are interacting. </ul><ul>Code-On-Demand Allows client functionality to be extended by downloading and executing code in the form of applets or scripts . This simplifies clients by reducing the number of features required to be pre-implemented. </ul>
  28. 28. Smart IT Engineering Ltd. REST Constraints <ul>Uniform Interface Central distinguishing feature of REST Involves four constraints to define 'uniform interface' for REST systems. <li>Identification of resources
  29. 29. Manipulation of resources through representations
  30. 30. Self-descriptive messages
  31. 31. HATEOAS ( H ypermedia A s T he E ngine O f A pplication S tate) </li></ul>
  32. 32. Smart IT Engineering Ltd. REST Constraints <ul>Uniform Interface - Resource <li>Any concept that might be the target of an web-author's hypertext reference must fit within the definition of a resource.
  33. 33. A resource is a conceptual mapping to a set of entities , not the entity that corresponds to the mapping at any particular point in time.
  34. 34. If compared of Object Oriented aproach, Object if referrrable is a resource.
  35. 35. Examples of resources would Books, A Book, An Author, Authors, Authors of a Book, A Publisher, Categories of a Book, A Category etc. </li></ul>
  36. 36. Smart IT Engineering Ltd. REST Constraints <ul>Uniform Interface – Representations & Messages <li>A representation is a sequence of bytes describing a resource in a particular format.
  37. 37. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant.
  38. 38. Message consists of control data, metadata, messages and in some cases hyperlinks to resources.
  39. 39. Examples: Images (image/jpg, image/png, etc.), Markups (text/html, application/xml etc.) and more. </li></ul>
  40. 40. Smart IT Engineering Ltd. REST Constraints <ul>Uniform Interface – HATEOAS <li>A hypermedia in each server response will contain links that correspond to all the actions that the client can currently perform.
  41. 41. Therefore, dependent on the current application state, every server response describes the new actions that are available.
  42. 42. The server can change the range of allowable responses in a dynamic way, and a client should adapt its behavior to these changes.
  43. 43. A client of a RESTful application need only know a single fixed URL to access it. </li></ul>
  44. 44. Smart IT Engineering Ltd. REST Constraints <ul>Uniform Interface – HATEOAS <li>All future actions should be discoverable dynamically from hypermedia links included in the representations of the resources that are returned from that URL.
  45. 45. The link relations should be standardized , so that the client knows what selecting that state transition means.
  46. 46. Standardized media types are also expected to be understood by any client that might use the API.
  47. 47. Application state transitions are driven by a combination of the known processing rules for each media type, client selection from the server-provided choices in representations received, and the user's manipulation of those representations. Thus interactions are driven by hypermedia . </li></ul>
  48. 48. Smart IT Engineering Ltd. REST What is the biggest known RESTful System on planet Earth?
  49. 49. Smart IT Engineering Ltd. REST World Wide Web a.k.a Internet <ul><li>HTTP Web Pages </li><ul><li>HTML pages are hypermedia </li><ul><li>CSS
  50. 50. Feeds
  51. 51. Media etc. </li></ul><li>JavaScript - Code-On-Demand </li></ul><li>Email </li><ul><li>Copy
  52. 52. Reply address </li></ul><li>FTP </li><ul><li>Files
  53. 53. Folders </li></ul></ul>
  54. 54. Smart IT Engineering Ltd. REST Questions?
  55. 55. Smart IT Engineering Ltd. RESTful Web Service What is RESTful Web Service or API? Any system following fulfilling the constraints, thus definition, of REST is a RESTful Web Service.
  56. 56. Smart IT Engineering Ltd. RESTful Web Service <ul><li>RESTful Web Service system communicates over HTTP protocol
  57. 57. RESTful Web Service design and architecture grows around resource .
  58. 58. All WWW sites are inherently REST-like and can easily be RESTful hence RESTful Web Service; e.g. Google Search Engine.
  59. 59. Web Service not only consists of either HTML markups, CSS and JavaScript, or other media formats, but may consist both </li></ul>
  60. 60. Smart IT Engineering Ltd. Resource Oriented Architecture <ul><li>Introduced in the book “RESTful Web Services”
  61. 61. Resource-Oriented Architecture is about REST-ful system with the technologies of the Web </li></ul>
  62. 62. Smart IT Engineering Ltd. ROA - Resource <ul><li>A Resource is anything, a concept, that is worth having a URI to linked to. E.g.
  63. 63. A URI is a name and address of a resource.
  64. 64. A Resource may have many URIs but needs to have at least one .
  65. 65. A Resource may have one or more representations; i.e. it may not have any representations at all. </li></ul>
  66. 66. Smart IT Engineering Ltd. ROA - Resource <ul><li>Having a nice URI is not mendatory as in REST clients do not form URIs rather discover them. So it is indifferent to have instead of as long as they name and address the same resource.
  67. 67. It does not hurt to have readable URIs
  68. 68. If Resource has multiple variants, i.e. combination of media format (atom xml, html etc.), encoding (ASCII, UTF-8 etc.) and language (en-US, bn etc.), besides supporting content negotiation, URI for each variant is beneficial for external linking. </li></ul>
  69. 69. Smart IT Engineering Ltd. ROA - Resource <ul>HTTP Hints <li>Content negotiation for representation in HTTP is done through request headers – Accept, Accept-Encoding, Accept-Language
  70. 70. Use Vary header in response in case a URI support multiple representations
  71. 71. Use Location header in response to specify the exact URI to the variant in case of nice URIs. </li></ul>
  72. 72. Smart IT Engineering Ltd. ROA - Features <ul>Key Features of ROA <li>Addressability
  73. 73. Statelessness </li><ul><li>Representations
  74. 74. Links & Connectedness </li></ul><li>The Uniform Interface
  75. 75. Safety & Idempotence </li></ul>
  76. 76. Smart IT Engineering Ltd. ROA - Addressability <ul><li>If an application exposes all conceivable or interesting aspects of its data set as resources then it is addressable.
  77. 77. IOW an addressable application exposes URI for every bit of information it can conceivably serve
  78. 78. This usually refers to infinite URIs
  79. 79. Consider a search resource, e.g. Google Search, A paginated atom feed of all books of a bookstore etc. </li></ul>
  80. 80. Smart IT Engineering Ltd. ROA - Statelessnes <ul><li>Same as that of REST
  81. 81. Introducing Application State and Resource State.
  82. 82. Application State resides on client side ensuring every request can be treated individually by the server without considering the past requests from the client
  83. 83. Resource State is data that makes up the resource. It resides server side and in case of write-able resource can be modified through its representation </li></ul>
  84. 84. Smart IT Engineering Ltd. ROA – Statelessnes Representations <ul><li>Lets consider a resource we call Book.
  85. 85. Book has name, ISBN only. (ignoring publisher, author(s) and categories for now).
  86. 86. It has 2 representations HTML and WWW URL Encoded.
  87. 87. Client can track how it reached the book in its client application state. Note different apps may reach to the same resource in different ways. E.g., one from Google Search another from a Facebook app.
  88. 88. The resource state, i.e. the current name and ISBN resides on the server side and is indifferent for any client.
  89. 89. Clients receive the representations of the resource and provides the server with the same to edit its information. </li></ul>
  90. 90. Smart IT Engineering Ltd. ROA – Statelessnes Link & Connectedness <ul><li>Lets enrich the Book dataset to contain author(s), publisher and categories.
  91. 91. So for every book resource there would be at least 5 related, i.e. Connected/Linked resource. They are the book's authors resource , the book's categories resource , the book's publisher resource , an author of the book (from first resource), a category of the book (from the 3 rd resource). </li></ul>
  92. 92. Smart IT Engineering Ltd. ROA – Resources /books /books/A /books/B /books/C /books/A/authors /books/A/publishers /pubs/A /authors/A /pubs/A/books /authors/A/books /pubs /authors /
  93. 93. Smart IT Engineering Ltd. ROA – Resource Templates /books /books/{id} /books/{id} /books/{id} /books/{id}/authors /books/{id}/publishers /pubs/{id} /authors/{id} /pubs/{id}/books /authors/{id}/books /pubs /authors /
  94. 94. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul><li>Specifies the generic definition of Uniform Interface from REST
  95. 95. The specifics are in context to HTTP
  96. 96. It basically follows the HTTP specification, does not change any definition but restricts on some of the operations usually performed
  97. 97. IMPORTANT – It remains same across all RESTful WS Providers, reducing learning curve. </li></ul>
  98. 98. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Methods <li>GET – To read resources. Query parameters can be used to restrict the scope of the data set
  99. 99. PUT – To create a resource if the URI is known or replace (completely) the current state of the resource
  100. 100. DELETE – Delete the current resource. Might not actually physically delete the data just change the state. </li></ul>
  101. 101. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Methods <li>POST – Has multiple functions </li><ul><li>Create sub-ordinate resource
  102. 102. Append state data to current resource, i.e. partially update the state of the resource
  103. 103. Submit data to some background process, e.g. POST to search data. </li></ul><li>The first 2 are uniform but the last is not and is advisable to avoid
  104. 104. In overloading POST with 2 ops one should consider breaking the resource to avoid overloading. </li></ul>
  105. 105. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Headers <li>For pre-condition based locking </li><ul><li>Entity Tag – ETag & If-Match
  106. 106. Last Modified Date – Last-Modified & If-Unmodified-Since
  107. 107. Implementation specific </li></ul><li>Client side caching </li><ul><li>Last Modified Date & Entity Tag for conditional GET using If-Modified-Since and If-None-Match
  108. 108. Cache-Control header for controlling cache
  109. 109. Use Vary to support variants. </li></ul><li>Use Location to redirect or point to the permanent URI </li></ul>
  110. 110. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Status (commonly used) <li>200 OK for returning success of request.
  111. 111. 201 Created for returning that resource is created, in conjunction with Location header pointing to the created resource.
  112. 112. 202 Accepted for returning that request accepted but will process at a later time without any guarantee.
  113. 113. 204 No Content for specifying no message entity </li></ul>
  114. 114. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Status (commonly used) <li>302 Found for redirecting, prefer 303 instead.
  115. 115. 303 See Other for redirecting using the Location header pointing to the actual resource.
  116. 116. 304 Not Modified for conditional GET when condition is unmet, i.e. client can server from client cache.
  117. 117. 301 Move Permanently If a resource URI has been changed, e.g. the template for books changed to /r/books from /books. </li></ul>
  118. 118. Smart IT Engineering Ltd. ROA – The Uniform Interface <ul>Status (commonly used) <li>400 Bad Request when request information is sufficient to process the data, e.g. required field of an HTML Form is missing.
  119. 119. 401 Unauthorized and 403 Forbidden for authentication and authorization failures respectively.
  120. 120. 404 Not Found for not being able to resolve the URI to a resuorce.
  121. 121. 406 Not Acceptable If none variants requested can be served by the server
  122. 122. 412 Preconditioned Failed if the conditions in request not met. Useful lock like feature in case of updates.
  123. 123. 415 Unsupported Media Type when request entity is not recognized by server for processing. </li></ul>
  124. 124. Smart IT Engineering Ltd. ROA – Safety & Idempotence <ul><li>If designed according to the spec we get safety and idempotence for free.
  125. 125. Safety – refers to GET and HEAD not changing any state of the resources concerned, but might have side effects, e.g. hit counters.
  126. 126. Idempotence – Repeating any one of PUT, POST, DELETE on a resource any number of will yield the same result. </li></ul>
  127. 127. Smart IT Engineering Ltd. RESTful vs RESTlike/REST-RPC Web Service <ul><li>Failures with my initial RESTful WS experiments </li><ul><li>Overloaded POST
  128. 128. Not realizing HATEOAS, i.e. Linked and Connectedness
  129. 129. Not realizing the strength of content negotiation, i.e. variant support
  130. 130. Not realizing strength of conditional requests
  131. 131. Not realizing the power of HTTP Cache </li></ul></ul>
  132. 132. Smart IT Engineering Ltd. RESTful Web Services & ROA Questions?
  133. 133. Smart IT Engineering Ltd. A Design Walk-through <ul><li>What remains unchanged? </li><ul><li>Use of HTTP as message vessel
  134. 134. Use of URI to address resources
  135. 135. No application state, i.e. session, on server side </li></ul><li>What changes? </li><ul><li>Resources and their interlinkings
  136. 136. Support of different media formats
  137. 137. Support of variants </li></ul></ul>
  138. 138. Smart IT Engineering Ltd. Design – Content Repository <ul><li>My Steps to design </li><ul><li>Identify domain objects using Object Oriented Approach
  139. 139. Identify cardinal relationships among domains
  140. 140. Identify resource templates from objects and their cardinal relations
  141. 141. Design uri templates for resource templates
  142. 142. Specify Entity tag generation algorithm for resources as applicable
  143. 143. Specify cache directives for resources
  144. 144. Choose supporting media types for resources </li></ul></ul>
  145. 145. Smart IT Engineering Ltd. Design – Content Repository <ul><li>Requirement
  146. 146. Contents can be separated logically in a boundary such that their definition and data can easily identified. Contents should extensively searchable, that is, by the logical partition definition type, free text etc. Contents and their fields can have multiple user configurable representations. All logical partitions should have featured contents. </li></ul>
  147. 147. Smart IT Engineering Ltd. Design – Content Repository <ul><li>Objects - /(search)? </li><ul><li>Workspace - /w/{workspaceId}(/search)? </li><ul><li>Representation Template - /w/{workspaceId}/reps(/{repId})?
  148. 148. Variation Template - /w/{workspaceId}/vars(/{varId})?
  149. 149. Root Contents a.k.a. Container - /w/{workspaceId}/container </li><ul><li>Contents </li></ul><li>Friendly Workspace - /w/{workspaceId}/friendlies
  150. 150. Content types - /w/{workspaceId}/types </li></ul><li>Content - /c/{workspaceId}/{contentId} </li><ul><li>Field - /c/{workspaceId}/{contentId}/fields(/{fieldName})? </li><ul><li>Variation - /c/{workspaceId}/{contentId}/fields/{fieldName}/{varId} </li></ul><li>Representation - /c/{workspaceId}/{contentId}/fields(/{repId})? </li></ul><li>Content Type -/t/{workspaceId}/{contentTypeId}(/search)? </li></ul></ul>
  151. 151. Smart IT Engineering Ltd. Design – Content Repository <ul><li>Objects - /(search)? </li><ul><li>Workspace - /w/{workspaceId}(/search)?
  152. 152. Content Type -/t/{workspaceId}/{contentTypeId}(/search)? </li></ul><li>The later 2 searches URIs are equivalent of </li><ul><li>/search?workspace={workspaceId}
  153. 153. /search?workspace={workspaceId}&type={typeId} </li></ul></ul>
  154. 154. Smart IT Engineering Ltd. Design – Content Repository <ul><li>Media Types </li><ul><li>Collections </li><ul><li>Atom Feed
  155. 155. Text URI-list </li></ul><li>Single Objects </li><ul><li>JSON
  156. 156. HTTP URL Encoded (Write only) </li></ul><li>Search </li><ul><li>HTML using Form
  157. 157. XForms in XML
  158. 158. Open Search Description (my only preference) </li></ul></ul></ul>
  159. 159. Smart IT Engineering Ltd. Design Questions? [email_address]