An Introduction to REST and RESTFul service concept

1. An introduction to REST Demonstrated by : Shubho http://www.linkedin.com/in/thisisshubho

2. What is REST? Stands for Representational State Transfer. Not a Standard or Framework, rather, an Architectural style for developing web based systems. Was proposed by “Roy Fielding” on 2000, one of the founder of World Wide Web.

3. Motivation To utilize the basic characteristics of the Web which made the Web successful. Utilizes the basic HTTP verbs to accomplish the basic CRUD operations: GET : For reading/getting the data POST : For creating the data PUT : For updating the data DELETE : For deleting the data

4. Basic Philosophy Everything is resource on the world wide web, which is identified by a URL, which his obviously Unique. The representation of the resource could vary. It could be HTML, XML, Jason etc. The representation of the resource places the client in a particular state. The client activity on a particular state (Say, a URL click) returns another representation and places the client into another state. Hence, the state transfer is occurring by representation of the resource.

5. Basic Architecture Used in a Client-Server scenario where the Client is a system, rather than human. Client uses basic HTTP verbs to perform CRUD operations on Server. Server processes operation and sends response as lightweight XML, which are just wrapper XML s to the data they return, and, which is readable both by human and system. Client parses the XML and retrieve the server data.

6. Why not Web service? Web Service uses SOAP, which are heavyweight as has lots of SOAP elements for describing data and managing several things. The XML (Representation) is not human readable. Not easy to consume, framework or toolkit is required (Say, you can’t use SOAP message to consume by javaScript) SOAP messages are not cacheable.

7. Advantages of REST Services are resource, just like Image resource or HTML resource (BIG Conceptual difference) Lightweight XML, consumes less bandwidth Human readable Can be consumed easily by client application. (Say, javascript can easily parse and consume a REST message, BIG advantage). In WCF, it’s a matter of one parameter to get Jason message as the REST message. REST messages are cacheable Client side reference not required.

8. Some negatives of REST Not as strongly typed as SOAP. Though, WCF makes it strongly typed. Works only with HTTP Calls to REST are restricted by HTTP Verbs (GET, POST, PUT, DELETE.. etc) Message structure is open, not standard.

9. Who uses REST? All of Yahoo's web services use REST, including Flickr, del.icio.us API, pubsub, bloglines, technorati. eBay, and Amazon have web services for both REST and SOAP. Flickr Meshups (An application that combines data/information from multiple different sources)

10. REST implementation in .NET The conventional Asp.net framework not suitable for implementing REST services. The WCF (Windows Communication Foundation) is the platform for implementing RESTful services. Along with, WCF could be used to consume the REST service (just like consuming web service) in a strongly typed fashion, without knowing the message structure.

11. Example Parts Depot, Inc (An imaginary company) wants to implement some RESTful web services to enable its customers to: Get a list of parts Get detailed information about a particular part Submit a Purchase Order (PO) Let's consider how each of these services are implemented in a RESTful fashion.

12. Example continued… A client system uses this URL to get the parts list: http://www.parts-depot.com/parts Here's the document that the client receives: <?xml version="1.0"?> <p:Parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/> </p:Parts>

13. Example continued… Note that the parts list has links to get detailed info about each part. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document. The web service makes URL available to each part resource. For example here's the URL the client hits to requests part 00345 detail information: http://www.parts-depot.com/parts/00345

14. Example continued… Here's the document that the client receives: <?xml version="1.0"?> <p:Part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part-ID>00345</Part-ID> <Name>Widget-A</Name> <Description>This part is used within the frap assembly</Description> <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost currency="USD">0.10</UnitCost> <Quantity>10</Quantity> </p:Part>

15. Example continued… Again observe how this data is linked to more data The specification for this part may be found by traversing the hyperlink. Each response document allows the client to drill down to get more detailed information.

16. Example continued… How to submit a Purchase Order? The web service makes URL available to submit a PO. The client creates a PO instance document which conforms to the PO schema that Parts Depot has designed (and publicized in a WSDL document). The client submits PO.xml and POST that xml to create a purchase order on the server.

17. Principle of RESTful design Identify all of the conceptual entities that you wish to expose as services. Consider those as resources. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this: http://www.parts-depot.com/parts/getPart?id=00345 Note the verb, getPart. Instead, use a noun: http://www.parts-depot.com/parts/00345 Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For just representing resource, make these accessible via GET. For allowing to modify data, make the resources accessible via PUT/POST/DELETE

18. Principle of RESTful design All resources accessible via HTTP GET should be side-effect free. That is, Invoking the resource should not result in modifying the resource Likewise, no representation should be an island. put hyperlinks within resource representations to enable clients to drill down for more information. Specify the format of response data using a schema. For those services that require a POST or PUT to it, also provide a schema to specify the format of the data you expect. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document

19. What is next? In the next session, we will see the WCF, which have implementation of the RESTful Service concept. Keep REST, be healthy!