Introduction To REST
Upcoming SlideShare
Loading in...5
×
 

Introduction To REST

on

  • 1,745 views

An Introduction to REST and RESTFul service concept

An Introduction to REST and RESTFul service concept

Statistics

Views

Total Views
1,745
Views on SlideShare
1,741
Embed Views
4

Actions

Likes
0
Downloads
23
Comments
0

3 Embeds 4

http://www.linkedin.com 2
https://www.mturk.com 1
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduction To REST Introduction To REST Presentation Transcript

    • An introduction to REST
      Demonstrated by : Shubho
      http://www.linkedin.com/in/thisisshubho
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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)
    • 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.
    • 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.
    • 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>
    • 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
    • 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>
    • 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.
    • 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.
    • 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
    • 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
    • What is next?
      In the next session, we will see the WCF, which have implementation of the RESTful Service concept.
      Keep REST, be healthy!