Your SlideShare is downloading. ×
Introduction To REST
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction To REST


Published on

An Introduction to REST and RESTFul service concept

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. An introduction to REST
    Demonstrated by : Shubho
  • 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, API, pubsub, bloglines, technorati.
    eBay, and Amazon have web services for both REST and SOAP.
    Meshups (An application that combines data/information from multiple different sources)
  • 10. REST implementation in .NET
    The conventional 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:
    Here's the document that the client receives:
    <?xml version="1.0"?>
    <p:Parts xmlns:p="" xmlns:xlink="">
    <Part id="00345" xlink:href=""/>
    <Part id="00346" xlink:href=""/>
    <Part id="00347" xlink:href=""/>
    <Part id="00348" xlink:href=""/>
  • 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:
  • 14. Example continued…
    Here's the document that the client receives:
    <?xml version="1.0"?>
    <p:Part xmlns:p="" xmlns:xlink="">
    <Description>This part is used within the frap assembly</Description> <Specification xlink:href=""/>
    <UnitCost currency="USD">0.10</UnitCost>
  • 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:
    Note the verb, getPart. Instead, use a noun:
    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!