1. Internet Technologies #6 REST SOAP AJAX

2. Agenda  REST  SOAP  AJAX

3. REST APPLICATION SERVERS TODAY

4. REST - what is it?  " REST " – was coined by Roy Fielding in his Ph.D. dissertation [1] to describe a design pattern for implementing networked systems. [1] http://www.ics.uci.edu/~fielding/pubs/dissertation /top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation /top.htm

5. How it works?  The Client references a Web resource using a URL.  A representation of the resource is  returned (in this case as an HTML document).  The representation (e.g., Boeing747.html) places the client in a new state.

6. How it works  When the client selects a hyperlink in Boeing747.html, it accesses another resource.  The new representation places the client application into yet another state.  Thus, the client application transfers state with each resource representation.

7. REST - what is it?  "Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state- machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."  - Roy Fielding

8. REST - what is it?  Not a standard!  Just a design pattern…  that prescribes the use of standards:  HTTP  URL  XML/HTML/GIF/JPEG/etc. (resource representations)  text/xml, text/html, image/gif, image/jpeg, etc. (MIME types)

9. REST - basics  Create a resource for every service.  Identify each resource using a URL.  The data that a Web service returns should link to other data. Thus, design your data as a network of information.  Contrast with OO design, which says to encapsulate information - don’t do it!

10. REST - basics  All interactions between a client and a web service are done with simple operations. Most web interactions are done using HTTP and just four operations:  retrieve information (HTTP GET)  create information (HTTP PUT)  update information (HTTP POST)  delete information (HTTP DELETE)

11. Features  platform independent  language independent  standards-based  no problems with firewalls etc.  No built in mechanisms for:  Security  Cryptography  Session management  Quality of Service  …

12. Used by…  …many serious services  Twitter  Amazon services(S3 storage solution)  Flickr  Atom  …

13. Resource representations  Often XML  but not the only available option  often:  CSV (for large amounts of data)  JSON (JavaScript Object Notation)

14. Recommendations  Don’t use physical URLs, use logical ones  http://www.acme.com/inventory/product003.xml http://www.acme.com/inventory/product003.xml  vs  http://www.acme.com/inventory/product/003 http://www.acme.com/inventory/product/003  Requests should not return large amounts of data  use paging  Don’t change resource formats lightly  provide additional ones

15. Recommendations  Don’t make the client to construct new action URLs  make them a part of the resource  GET requests should not change server state - this is what POST, DELETE, PATCH and so on are for…  Don’t rely on cookies and so on

16. SOAP web services

17. Web Services  A Web service is a method of communication between two electronic devices over a network. It is a software function provided at a network address over the Web with the service always on as in the concept of utility computing.

18. Web Services  encapsulated - implementation is not visible to the user  loosely coupled - modifications of implementation (not interface!) should not generate the change propagation problem  contracted - descriptions of functions and their interface specifications are publicly available

19. WS architecture  client,  service provider  service broker (optional)  publishing of service descriptions  service lookup

20. WS architecture

21.  use of specific, popular technologies  URL for addressing  SOAP for transport (HTTP- based)  XML as message format

22. SOAP  stateless, one-way protocol based on HTTP  may utilize other protocols (nobody does it really)  allows construction of more complex communication models  specifies structure for XML message exchange  mandatory and optional message elements  encoding and transmission  does not determine application semantics, coding paradigm etc.

23. WSDL  W3C specification used to provide machine-readable WS description  Based on XML  Defines service interface, not service semantics  abstract interface - independent from transport protocol or programming language

24. WSDL  definition contains the general part:  data types definitions  message definitions  port type definitions  and the specific part  binding definitions  service definitions

25. UDDI  Universal Description, Discovery and Integration  White Pages – address, contact, identifiers  Yellow Pages - categorization based on predefined taxonomies  Green Pages – technical informations

26. UDDI  Specification published in 2000  Vision of widely available services  commercial  dynamically integrated with applications  Last public UDDI nodes maintained by Microsoft, IBM and SAP closed in January 2006

27. Web Services in practice  Two service construction scenarios:  Top-down:  design the service  create WSD  generate stub and skeleton  implement  Bottom-up:  take existing implementation  generate WSDL based on it, create stubs and skeletons from it

28. Web Services in practice  multiple additional specifications  WS-Security  WS-Signature  WS-Encryption  WS-Trust  WS-Notification  …

29. AJaX

30.  Old ideas come back in new form  Cycles in the approach to application architecture:  Terminals  „thick” client applications  web pages  dynamic web pages

31. AJaX  Drawbacks of „thin” web page applications:  user interface „feel” radically different in comparison to desktop applications

32. What is AJaX  A name given to an existing approach to building dynamic web applications  Web pages use JavaScript to make asynchronous calls to web-based services that typically return XML  Uses a JavaScript class called XMLHttpRequest

33. What is AJaX  allows user to continue interacting with web page while waiting for data to be returned  page can be updated without refreshing browser  results in a better user experience  there are AJaX libraries that reduce the amount of JavaScript code that must be written

34. What is AJaX  A is for “asynchronous”  requests can be made asynchronously or synchronously  both techniques allow web page to be updated without refreshing it  anything useful the user can do while processing request?  if yes then use asynchronous, otherwise use synchronous

35. What is AJaX  Ja is for “JavaScript”  typically JavaScript is used on the client-side (in the browser)  only programming language supported out-of-the- box by most web browsers  can use any language on server-side that can accept HTTP requests and return HTTP responses  Java servlets, Ruby servlets, CGI scripts, …

36. What is AJaX  X is for “XML”  request and response messages can contain XML  can really contain any text (single text value, delimited text, …)

37. What is AJaX  Traditional approach to building web applications:  URL used to navigate between web pages, but also as interaction tool  AJaX approach:  communication with server without sending requests for another page

38. Components of AJaX  XMLHttpRequest object  XML, XSLT – exchange and transformation of data  XHTML, CSS – standard presentation tools  DOM – interaction with document, document updates  JavaScript – client-side scripts

39. How it works  XMLHttpRequest - a JavaScript class supported by most web browsers  Allows HTTP requests to be sent from JavaScript code to send multiple, concurrent requests, use a different XMLHttpRequest instance for each  HTTP responses are processed by “handler” functions – in client-side JavaScript

40. First issue  code to create an XMLHttpRequest object differs between browsers  can use a JavaScript library to hide the differences

41. XMLHttpRequest Properties  (partial list)  readyState  0 = UNINITIALIZED; open not yet called  1 = LOADING; send for request not yet called  2 = LOADED; send called, headers and status are available  3 = INTERACTIVE; downloading response,  responseText only partially set  4 = COMPLETED; finished downloading response

42. XMLHttpRequest Properties  responseText  response as text; null if error occurs or ready state < 3  responseXML  response as DOM Document object; null if error occurs or ready state < 3  status – integer status code  statusText – string status  onreadystatechange – assign a function called on each state change

43. XMLHttpRequest Properties  (partial list)  Basic methods  open(method, url[, async]) – initializes a new HTTP request  method can be "GET", "POST", "PUT" or "DELETE"  url must be an HTTP URL (start with "http://")  async is a boolean indicating whether request should be sent asynchronously  defaults to true

44. XMLHttpRequest Properties  send(body) – sends HTTP request  abort() – called after send() to cancel request  void setRequestHeader(name, value)  String getResponseHeader(name)  String getAllResponseHeaders()  returns a string where „header: value” pairs are delimited by carriage returns

45. Sample call function getResource(url) { if (window.XMLHttpRequest) { // Mozilla etc. xhr =new XMLHttpRequest(); xhr.onreadystatechange=handleChange; // callback xhr.open("GET", url, true); xhr.send(null); } else if (window.ActiveXObject) { // Internet Exporer xhr=new ActiveXObject("Microsoft.XMLHTTP"); if (xhr) { xhr.onreadystatechange=handleChange; xhr.open("GET",url,true); xhr.send(); } } }

46. Sample response handler function handleChange() { if (xmlhttp.readyState==4) { if (xmlhttp.status==200) { //...get data, update view... }

47. Using JSON var my_JSON_object = {}; var http_request = new XMLHttpRequest(); http_request.open("GET", url, true); http_request.onreadystatechange = function () { var done = 4, ok = 200; if (http_request.readyState == done && http_request.status == ok) { my_JSON_object = JSON.parse (http_request.responseText); } }; http_request.send(null);

48. We’ve been here before…  The new part is the XMLHttpRequest object and asynchronous call (not really ;) ), the rest has been done before  Hidden Frames  IE5+, Mozilla 1.0+, Safari 1.2+, and Opera 7.6+  Java  Applets

49. Why is it popular?  Google helped popularize, and legitimize it in GMail  Increase Usability of Web Applications  Rich Internet Applications without Flash  Save Bandwidth  Download only data you need  Faster interfaces (sometimes)

50. Why is it bad?  Breaks back button support and bookmarking  URL's don't change as state changes  Cross Browser Issues can be a pain  JavaScript may tax older machines CPU  Can't access domains other than the calling domain  May be disabled (for security reasons) or not available on some browsers  Debugging is difficult

51. Why is Microsoft so evil?  As usual the IE handles things differently to the other browsers  but… they did this first  so it is rather hard to blame them  IE7 includes support for both „IE-style” and „rest of the world-style” HttpRequests…  there are some issues, however

52. When NOT to use AJaX  Just because it is cool and shiny  For navigation  To display static content

53. When you should use AJaX  Real-time user-server interaction  Validation of data based on server-side resources  Displaying content that should be hidden from search engines

54. Questions?