The document discusses RESTful web services and Resource Oriented Architecture (ROA). It defines REST and its constraints including client-server architecture, statelessness, cacheability, uniform interface and layered system. It then explains ROA and how resources are addressed and represented in a RESTful system. Key concepts like addressability, statelessness, representations, links and connectedness, uniform interface and safety are covered in relation to ROA. The document provides examples and discusses designing a RESTful API for a content management system.
41. Therefore, dependent on the current application state, every server response describes the new actions that are available.
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. A client of a RESTful application need only know a single fixed URL to access it.
44.
45. The link relations should be standardized , so that the client knows what selecting that state transition means.
46. Standardized media types are also expected to be understood by any client that might use the API.
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 .
48. Smart IT Engineering Ltd. REST What is the biggest known RESTful System on planet Earth?
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.
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.
69.
70. Use Vary header in response in case a URI support multiple representations
71. Use Location header in response to specify the exact URI to the variant in case of nice URIs.
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. 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
84.
85. Book has name, ISBN only. (ignoring publisher, author(s) and categories for now).
86. It has 2 representations HTML and WWW URL Encoded.
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. The resource state, i.e. the current name and ISBN resides on the server side and is indifferent for any client.
89. Clients receive the representations of the resource and provides the server with the same to edit its information.
90.
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).
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.