12 Web Services REresentation State Transfer (REST) CA464: DISTRIBUTED PROGRAMMING 1. More on Distributed Web Services: REST

Transcription

1 CA464: DISTRIBUTED PROGRAMMING 1 12 Web Services 12.1 REresentation State Transfer (REST) More on Distributed Web Services: REST Architecture REST, or Representational State Transfer, is a distributed communication architecture fast becoming the lingua franca for Cloud Computing. The central abstraction in REST is the Resource. A resource in the RESTful sense is anything that has an URI. In practice, a resource is an informational item that has hyperlinks to it. Contrast Between SOAP & REST Essence: REST & SOAP are quite different SOAP is a messaging protocol, REST is a architectural style. SOAP uses WSDL for comms, REST exchanges data in XML/JSON 1. SOAP calls services by RPCs, REST invokes them via URL path. SOAP can be over other protocols, REST is only over HTTP. 1 a more lightweight, human parsable data exchange format than XML

2 CA464: DISTRIBUTED PROGRAMMING 2 Contrast Between SOAP & REST Cont d REST tries to isolate complexity at endpoints (Clients & Service): Service: could need to logic/computation to process XML to maintain Resources & generate their representation. Client: may have to process XML to extract info from XML representation. But this complexity is kept from the transport level. SOAP complicates the transport level as a SOAP message is encapsulated as transport message body. More on Resources Resources have certain properties: Representation: usually MIME (commonly text/html, text/xml). State: i.e. they are mutable. Note: In a RESTful request on a resource, the resource itself stays on the service-side. If the request succeeds, the requester gets the resource s representation (this transfers from the server to the requester machine). For a successful request to read a resource, it s typed representation (e.g. text/html) transfers from the resource s server to the requester. Recall: HTTP (REST) Operations Essence Communication in the Web is generally based on HTTP. Operation Idempotent? Description Head Yes Request to return the header of a document Get Yes Request to return a document to the client Put Yes Request to store a document Post No Provide data that are to be added to a document (collection) Delete Yes Request to delete a document in REST Shown below is a client comms with a resource & the typed responses it gets: GET request could return my biography (html or video). Typical html resource representations could have other resource links. These could then be the target of HTTP requests with appropriate CRUD verbs.

3 for the resource. Each HTTP request includes a verb to indicate which CRUD operation should be performed on the resource. A good representation is precisely one that matches the requested operation and captures the resource s state in some appropriate way. For example, in this depiction a GET request could return my biography as a hacker as either an HTML document or a short video summary. The video would fail CA464: DISTRIBUTED to capture the PROGRAMMING state of the resource if it depicted, say, only the major disasters in my 3 brother s career rather than those in my own. A typical HTML representation of the resource would include hyperlinks to other resources, which in turn could be the target of HTTP requests with the appropriate CRUD verbs. Identifying URL: Resource: My life as a hacker HTTP requests GET: Read POST: Create PUT: Update DELETE: Delete HTTP responses MIME-typed representations of the resource such as: GET: HTML page with my hacker s bio GET: Short video of major disasters PUT: Plain text acknowledgement of update POST: Fancy HTML acknowledgement of resource creation RESTful client Figure 4-1. A small slice of a RESTful system HTTP also has standard response codes, such as 404 to signal that the requested resource could ofnot URIs be found, and 200 to signal that the request was handled successfully. A Subtlety: Opacity In short, HTTP provides request verbs and MIME types for client requests and status A URI is meant codes to be (and opaque MIME types) for service responses. This means Modern thatbrowsers the URI: generate only GET and POST requests. Moreover, many applications treat these two types of requests interchangeably. For example, Java HttpServlets have has no inherent connection to the URI: callback methods such as doget and dopost that handle GET and POST requests, re- Fred happens Each callback to be a has citizen the same of Bedrock. parameter types, HttpServletRequest (the key/ althoughspectively. value pairs from the requester) and HttpServletResponse (a typed response to the requester). It is common to have the two callbacks execute the same code (for instance, A Note of caution by having one invoke the other), thereby conflating the original HTTP distinction between read and create. A key guiding principle of the RESTful style is to respect the Of course, original good meanings designers of the devise HTTP URIs verbs. akin In particular, to whatany they GET identify, request but should URIs be side have no intrinsiceffect-free hierarchical (or, structure. in jargon, idempotent) because a GET is a read rather than a create, update, or delete operation. A GET as a read with no side effects is called a safe GET. URI syntax resembles that for file system navigation, but this can mislead; URIs are opaque identifiers, The REST approach each naming does not exactly imply one that either resource. resources or the processing needed to generate adequate representations of them are simple. A REST-style web service might be every bit as subtle and complicated as a SOAP-based service. The RESTful approach A Ruby Client on a Web Service Using Ruby s Rest Client.gem with CrunchBase REST interface What Is REST? 123 Here we use Rest Client.gem (e.g. with interactive Ruby shell irb). URI is a CrunchBase request given to Rest Client s Get method. If you want, emit the resp.body, (& see all JSON data returned). You can use the JSON.parse method to parse the response into a Ruby object structure. Finally, extract the desired value ( 'number of employees=50' here). A Ruby Client on a Web Service (cont d) Here, a Ruby Client uses Rest Client.gem to make life easier.

4 CA464: DISTRIBUTED PROGRAMMING 4 #!/usr/bin/env ruby require 'rest_client' #require 'json' #require 'net/http' // don't need as rest_client.gem has all these // don't need as rest_client.gem has all these class def initialize end end def print_data (company="ibm") // default value is "IBM" base_url=" key="6y hw" // my key; you have to get your own company="whatsapp" // the company url="#{base_url}/v/1/company/#{company}.js?api_key=#{key}" puts url // echo url variable to screen resp=restclient.get url // call // output whatsapps roll no. end if FILE == $0 mg = Crunchery.new ("whatsapp") mg.print_data puts "end reached" // Main File to run the above // See output below C:\Ruby193>ruby Crunchery.rb key=6y 50 end reached hw A User Interface Client on a Web Service The RestClient UI Get s Bookmarks from Bibsonomy.com. Note: password is user hash from registration with Bibsonomy.com.

5 CA464: DISTRIBUTED PROGRAMMING 5 The bookmark results of the previous Get operation. RestClient uses Post to add a Bookmark to Bibsonomy.com. Note: Change content-type to application/xml & charset to UTF-8. Nb! The bookmark results of the previous Post operation.

6 CA464: DISTRIBUTED PROGRAMMING 6 Success! Take note of hash needed later! RestClient uses Put to change a Bookmark thus Use of hash to alter/delete Nb! The bookmark results of the previous Put operation.

7 CA464: DISTRIBUTED PROGRAMMING 7 Success! New Tag: HypochondriaStuff RestClient uses Delete to remove a Bookmark thus Use of hash to alter/delete Nb! The bookmark results of the previous Delete operation.

8 CA464: DISTRIBUTED PROGRAMMING 8 Success!