RESTful Web Services

Head of Engineering at NewsCred
Feb. 5, 2011

More Related Content


RESTful Web Services

  1. Smart IT Engineering Ltd. RESTful Web Services Imran M Yousuf Smart IT Engineering Ltd.
  2. Hands on tutorial on how code a RESTful WS
  3. Details of how HTTP works
  4. Details on various media formats
  5. Discussion on its constraints
  6. Constraints of ROA
  7. Examples
  8. Questions
  9. Proposed by Dr. Roy Thomas Fielding in his PhD dissertation titled - “Architectural Styles and the Design of Network-based Software Architectures”
  10. REST is an architectural style composed of specific constraints.
  11. The Constraints - - Client-Server - Stateless - Cache - Uniform Interface - Layered System - Code-On-Demand (Optional)
  12. No restrictions on the number of the clients
  13. No restriction on communication medium / protocol Client (Browser) Client (CLI – curl, wget) Client (Desktop) Network Client (Mobile) Client (Another System)
  14. Improve user interface portability across multiple platforms
  15. Improve scalability by simplifying server components
  16. Components evolve independently
  17. Manipulation of resources through representations
  18. Self-descriptive messages
  19. HATEOAS ( H ypermedia A s T he E ngine O f A pplication S tate)
  20. 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.
  21. If compared of Object Oriented aproach, Object if referrrable is a resource.
  22. Examples of resources would Books, A Book, An Author, Authors, Authors of a Book, A Publisher, Categories of a Book, A Category etc.
  23. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant.
  24. Message consists of control data, metadata, messages and in some cases hyperlinks to resources.
  25. Examples: Images (image/jpg, image/png, etc.), Markups (text/html, application/xml etc.) and more.
  26. Therefore, dependent on the current application state, every server response describes the new actions that are available.
  27. The server can change the range of allowable responses in a dynamic way, and a client should adapt its behavior to these changes.
  28. A client of a RESTful application need only know a single fixed URL to access it.
  29. The link relations should be standardized , so that the client knows what selecting that state transition means.
  30. Standardized media types are also expected to be understood by any client that might use the API.
  31. 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 .
  32. Smart IT Engineering Ltd. REST What is the biggest known RESTful System on planet Earth?
  33. Feeds
  34. Folders
  35. Smart IT Engineering Ltd. REST Questions?
  36. 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.
  37. RESTful Web Service design and architecture grows around resource .
  38. All WWW sites are inherently REST-like and can easily be RESTful hence RESTful Web Service; e.g. Google Search Engine.
  39. Web Service not only consists of either HTML markups, CSS and JavaScript, or other media formats, but may consist both
  40. Resource-Oriented Architecture is about REST-ful system with the technologies of the Web
  41. A URI is a name and address of a resource.
  42. A Resource may have many URIs but needs to have at least one .
  43. A Resource may have one or more representations; i.e. it may not have any representations at all.
  44. It does not hurt to have readable URIs
  45. 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.
  46. Use Vary header in response in case a URI support multiple representations
  47. Use Location header in response to specify the exact URI to the variant in case of nice URIs.
  48. Safety & Idempotence
  49. IOW an addressable application exposes URI for every bit of information it can conceivably serve
  50. This usually refers to infinite URIs
  51. Consider a search resource, e.g. Google Search, A paginated atom feed of all books of a bookstore etc.
  52. Introducing Application State and Resource State.
  53. Application State resides on client side ensuring every request can be treated individually by the server without considering the past requests from the client
  54. 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
  55. Book has name, ISBN only. (ignoring publisher, author(s) and categories for now).
  56. It has 2 representations HTML and WWW URL Encoded.
  57. 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.
  58. The resource state, i.e. the current name and ISBN resides on the server side and is indifferent for any client.
  59. Clients receive the representations of the resource and provides the server with the same to edit its information.
  60. 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).
  61. 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 /
  62. 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 /
  63. The specifics are in context to HTTP
  64. It basically follows the HTTP specification, does not change any definition but restricts on some of the operations usually performed
  65. IMPORTANT – It remains same across all RESTful WS Providers, reducing learning curve.
  66. PUT – To create a resource if the URI is known or replace (completely) the current state of the resource
  67. DELETE – Delete the current resource. Might not actually physically delete the data just change the state.
  68. Append state data to current resource, i.e. partially update the state of the resource
  69. In overloading POST with 2 ops one should consider breaking the resource to avoid overloading.
  70. Last Modified Date – Last-Modified & If-Unmodified-Since
  71. Cache-Control header for controlling cache
  72. 201 Created for returning that resource is created, in conjunction with Location header pointing to the created resource.
  73. 202 Accepted for returning that request accepted but will process at a later time without any guarantee.
  74. 204 No Content for specifying no message entity
  75. 303 See Other for redirecting using the Location header pointing to the actual resource.
  76. 304 Not Modified for conditional GET when condition is unmet, i.e. client can server from client cache.
  77. 301 Move Permanently If a resource URI has been changed, e.g. the template for books changed to /r/books from /books.
  78. 401 Unauthorized and 403 Forbidden for authentication and authorization failures respectively.
  79. 404 Not Found for not being able to resolve the URI to a resuorce.
  80. 406 Not Acceptable If none variants requested can be served by the server
  81. 412 Preconditioned Failed if the conditions in request not met. Useful lock like feature in case of updates.
  82. 415 Unsupported Media Type when request entity is not recognized by server for processing.
  83. Safety – refers to GET and HEAD not changing any state of the resources concerned, but might have side effects, e.g. hit counters.
  84. Idempotence – Repeating any one of PUT, POST, DELETE on a resource any number of will yield the same result.
  85. Not realizing HATEOAS, i.e. Linked and Connectedness
  86. Not realizing the strength of content negotiation, i.e. variant support
  87. Not realizing strength of conditional requests
  88. Not realizing the power of HTTP Cache
  89. Smart IT Engineering Ltd. RESTful Web Services & ROA Questions?
  90. Use of URI to address resources
  91. Support of different media formats
  92. Support of variants
  93. Identify cardinal relationships among domains
  94. Identify resource templates from objects and their cardinal relations
  95. Design uri templates for resource templates
  96. Specify Entity tag generation algorithm for resources as applicable
  97. Specify cache directives for resources
  98. Choose supporting media types for resources
  99. 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.
  100. Variation Template - /w/{workspaceId}/vars(/{varId})?
  101. /search?workspace={workspaceId}&type={typeId}
  102. XForms in XML
  103. Open Search Description (my only preference)
  104. Smart IT Engineering Ltd. Design Questions? [email_address]