Introduction To REST


Published on

An Introduction to REST and RESTFul service concept

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction To REST

  1. 1. An introduction to REST<br />Demonstrated by : Shubho<br /><br />
  2. 2. What is REST?<br />Stands for Representational State Transfer.<br />Not a Standard or Framework, rather, an Architectural style for developing web based systems.<br />Was proposed by “Roy Fielding” on 2000, one of the founder of World Wide Web.<br />
  3. 3. Motivation<br />To utilize the basic characteristics of the Web which made the Web successful.<br />Utilizes the basic HTTP verbs to accomplish the basic CRUD operations:<br />GET : For reading/getting the data<br />POST : For creating the data<br />PUT : For updating the data<br />DELETE : For deleting the data<br />
  4. 4. Basic Philosophy<br />Everything is resource on the world wide web, which is identified by a URL, which his obviously Unique.<br />The representation of the resource could vary. It could be HTML, XML, Jason etc.<br />The representation of the resource places the client in a particular state.<br />The client activity on a particular state (Say, a URL click) returns another representation and places the client into another state.<br />Hence, the state transfer is occurring by representation of the resource.<br />
  5. 5. Basic Architecture<br />Used in a Client-Server scenario where the Client is a system, rather than human.<br />Client uses basic HTTP verbs to perform CRUD operations on Server.<br />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.<br />Client parses the XML and retrieve the server data.<br />
  6. 6. Why not Web service?<br />Web Service uses SOAP, which are heavyweight as has lots of SOAP elements for describing data and managing several things.<br />The XML (Representation) is not human readable.<br />Not easy to consume, framework or toolkit is required (Say, you can’t use SOAP message to consume by javaScript)<br />SOAP messages are not cacheable.<br />
  7. 7. Advantages of REST<br />Services are resource, just like Image resource or HTML resource (BIG Conceptual difference)<br />Lightweight XML, consumes less bandwidth<br />Human readable<br />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.<br />REST messages are cacheable<br />Client side reference not required.<br />
  8. 8. Some negatives of REST<br />Not as strongly typed as SOAP. Though, WCF makes it strongly typed.<br />Works only with HTTP<br />Calls to REST are restricted by HTTP Verbs (GET, POST, PUT, DELETE.. etc)<br />Message structure is open, not standard.<br />
  9. 9. Who uses REST?<br />All of Yahoo's web services use REST, including Flickr, API, pubsub, bloglines, technorati. <br />eBay, and Amazon have web services for both REST and SOAP.<br />Flickr<br />Meshups (An application that combines data/information from multiple different sources)<br />
  10. 10. REST implementation in .NET<br />The conventional framework not suitable for implementing REST services.<br />The WCF (Windows Communication Foundation) is the platform for implementing RESTful services.<br />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.<br />
  11. 11. Example<br />Parts Depot, Inc (An imaginary company) wants to implement some RESTful web services to enable its customers to: <br />Get a list of parts<br />Get detailed information about a particular part<br />Submit a Purchase Order (PO) <br /> Let's consider how each of these services are implemented in a RESTful fashion. <br />
  12. 12. Example continued…<br />A client system uses this URL to get the parts list:<br /> <br />Here's the document that the client receives:<br /><?xml version="1.0"?> <br /><p:Parts xmlns:p="" xmlns:xlink=""> <br /><Part id="00345" xlink:href=""/> <br /><Part id="00346" xlink:href=""/> <br /><Part id="00347" xlink:href=""/> <br /><Part id="00348" xlink:href=""/> <br /></p:Parts> <br />
  13. 13. Example continued…<br />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. <br />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:<br /> <br />
  14. 14. Example continued…<br />Here's the document that the client receives:<br /><?xml version="1.0"?> <br /><p:Part xmlns:p="" xmlns:xlink=""> <br /><Part-ID>00345</Part-ID> <br /><Name>Widget-A</Name> <br /><Description>This part is used within the frap assembly</Description> <Specification xlink:href=""/> <br /><UnitCost currency="USD">0.10</UnitCost> <br /><Quantity>10</Quantity> <br /></p:Part><br />
  15. 15. Example continued…<br />Again observe how this data is linked to more data <br />The specification for this part may be found by traversing the hyperlink. <br />Each response document allows the client to drill down to get more detailed information.<br />
  16. 16. Example continued…<br />How to submit a Purchase Order?<br />The web service makes URL available to submit a PO. <br />The client creates a PO instance document which conforms to the PO schema that Parts Depot has designed (and publicized in a WSDL document). <br />The client submits PO.xml and POST that xml to create a purchase order on the server.<br />
  17. 17. Principle of RESTful design<br />Identify all of the conceptual entities that you wish to expose as services. Consider those as resources.<br />Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:<br /> <br /> Note the verb, getPart. Instead, use a noun:<br /> <br />Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource.<br />For just representing resource, make these accessible via GET. <br />For allowing to modify data, make the resources accessible via PUT/POST/DELETE<br />
  18. 18. Principle of RESTful design<br />All resources accessible via HTTP GET should be side-effect free. That is, Invoking the resource should not result in modifying the resource<br />Likewise, no representation should be an island. put hyperlinks within resource representations to enable clients to drill down for more information.<br />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.<br />Describe how your services are to be invoked using either a WSDL document, or simply an HTML document<br />
  19. 19. What is next?<br />In the next session, we will see the WCF, which have implementation of the RESTful Service concept.<br />Keep REST, be healthy!<br />