1. Representational State Transfer (REST)

2. What is REST? Network Architectural style Overview: –Resources are defined and addressed –Transmits domain-specific data over HTTP

3. REST is not a standard No W3C specification (EDIT: But there is an XML database that has such an API: eXist) REST is built on the concepts: –HTTP (transferring mechanism) –URL (resource address) –XML/HTML/GIF/JPEG (Resource representations) –text/xml, text/html, image/gif, image/jpeg (MIME types)

4. Web services: example Build a web service to enable its customers to –Get list of items –Get details about a particular item –Purchase Order (PO)

5. Web Server HTTP POST PO.xml PO (HTML/XML) HTTP GET request /items HTTP response URL to submitted PO List of Items Item Data PO HTTP response Response (HTML/XML doc) HTTP response Response (HTML/XML doc) HTTP GET request /00345 Time A user session

6. Get list of items Access the URL: http://www.company.com/items How the list is generated is invisible to the user (loose coupling) The following XML document returned: Each item is retrieved via other links (key feature)

7. Get detail of an item Accessing the URL: http://www.company.com/items/00345http://www.company.com/items/00345 Any data change will not affect the user as in accessing http://www.company.com/items/00345.html (restricts the resource; whereas a database could be underneath) http://www.company.com/items/00345.html Again, more in-depth links appear, enabling to more detailed information

8. Characteristics Traversing links pulls representations (pull-based client-server interaction) Each request must be self-sufficient, not taking advantage of any store resource (stateless) Capability of storing responses to frequent requests (cacheable or non-cacheable) Resources are access via (HTTP) GET, POST, PUT, DELETE (uniform interface) Every resource is named using an URL (named resources) Resources are interconnected using URLs (interconnected resource representations) Intermediate components, e.g. proxy servers, gateways, firewalls, etc. can be inserted between clients and resources for performance, security (layered components)

9. Steps in creating a RESTful system 1.Identify resources, e.g. list of items, detail of an item, purchase order 2.Create a URL for every resource [use nouns, not verbs] http://www.company.com/items/00345 Instead of http://www.company.com/items/getItem?id=00345 3.Categorize resources: Accessible via HTTP GET (read-only) Accessible also via POST, PUT, DELETE (modifiable) 4.Connect resources through hyperlinks 5.Specify the format of the response using a schema, e.g. DTD, W3C schema, RelaxNG (also take care of POST or PUT services) 6.Describe how your services should be invoked (in a WSDL or HTML document)

10. REST Constrains (2) Uniform interface constrain –Implementation decoupled from interfaces -Adapting degrades efficiency -Layered system constraint -Architecture can be build hierarchically -Added Overhead -Code-on-demand (inactive code is executed on the client when the user requests it)

11. Advantage to SOAP technology StructureAccessibilityExtensibility PerformanceSecurity REST Inter- connections (hyperlinks) GET, PUT, POST, DELETE (uniform interface) Yes, through links GET-base URIs are cacheable Can apply {GET, PUT, POST, DELETE} permissions to a data object SOAP RPC OO paradigm of encapsulating data Specific and numerous methods Cannot refer to other objects outside the system Not cached by any existing technology Have to implement suitable strategy