1. 1 © Copyright 2010 Dieter Fensel, Jacek Kopecky and Srdjan Komazec Semantic Web Services Web2.0 services

2. 2 Where are we? #Title 1Introduction 2Web Science 3Service Science 4Web services 5Web2.0 services 6Semantic Web 7Web Service Modeling Ontology (WSMO) 8Web Service Modeling Language (WSML) 9Web Service Execution Environment (WSMX) 10OWL-S and other 11Light-weight Annotations 12Applications 13Mobile Services

3. 3 Outline Motivation Technical solution –RESTful Web Services –Current "REST-like" services –Describing and consuming RESTful services –Authentication considerations Examples Summary Resources

4. 4 MOTIVATION

5. 5 Motivation Web 2.0 & RESTful Services Early Web was about information Then it grew with commerce Now it becomes interactive –AJAX user interfaces –Web application APIs Machine-oriented Web resources –Web of Services

6. 6 Motivation What is Web 2.0? Depends who you ask, but mainly: 1.Read-write Web 2.Democratized/Social Web 3.Mature Web 4.Programmable Web

7. 7 Motivation Why Programmable Web 1 Read-write Web needs user participation –Web sites need the data from users –E.g. flickr, del.icio.us, facebook Make it easy for users to contribute –Many applications for uploading pictures to flickr –Bookmarklets to add a del.icio.us bookmark –Notifying facebook of blog posts, new pictures, tweets

8. 8 Motivation Why Programmable Web 2 Democratized and Social Web Web sites don't treat users as consumers –Prosumer = producer + consumer –Pushing boundaries: privacy, trust, IPR The users own their data –Export APIs for application sync, backup, migration –E.g. calendar in vCal, friends in FOAF –Without screen scraping

9. 9 Motivation Why Programmable Web 3 Mature Web: things really work now –AJAX, fast pipes –E.g. Google maps: interactive vast images AJAX makes the browser smarter –The AJAX code accesses the Web server as a service

10. 10 Motivation Programmable Web Javascript can do more –Update a part of a page on the fly, without the full HTTP roundtrip Desktop apps can work with Web apps –Flickr uploadr, calendar update/sync Web apps can work with others –LinkedIn can import your Facebook friends –Facebook can import your Dopplr trips Mashups: easy service composition

11. 11 Motivation Mashup: Housingmaps.com

12. 12 Motivation Web APIs & Services Data providers –Google maps, Geonames, phone location… –Microformats (vcard, calendar, review…) –Data feeds Functionality –Publishing, messaging, payment… Reverse APIs: Human computation –Amazon Mechanical Turk, ESP game… Web as a Platform

13. 13 TECHNICAL SOLUTION RESTful Web Services

14. 14 RESTful WS Definition A RESTful Web service is: –A set of Web resources –Interlinked –Data-centric, not functionality-centric –Machine-oriented Like Web applications, but for machines Like WS-*, but with more Web resources

15. 15 WS-  vs REST: A quick comparison WS-  collection service collection entry listEntries() addEntry() getEntry() deleteEntry() updateEntry() listEntries() addEntry() getEntry() deleteEntry() updateEntry() RESTful

16. 16 Technologies Todays’s set of technologies, protocols and languages used to apply RESTful paradigm: –HTTP as the basis –REST as the architectural style of the Web –XML and JSON for data exchange –AJAX for programming the browser Examples –Flickr Image management –AtomPub Feeds, publishing, syndication

17. 17 Web Requirements Simplicity, low barrier of entry Extensibility –To allow growth past simplicity Distributed hypermedia Anarchic scalability Independent deployment –Coexistence of old and new Human-oriented optimizations –Latency, usability

18. 18 HTTP Quick Overview Addressing resources with http:// URIs Request/response, four methods: –GET – information retrieval (safe) –POST – adding data for processing –PUT – replacing resource content –DELETE – removing resource Commonly, a response contains links to further resources

19. 19 REST Overview REST principles –Resources Architectural style –Set of architectural constraints –Not a concrete architecture –An architecture may adopt REST constraints HTTP the main implementation of REST –Should not be confused

20. 20 Major REST principles Information is organized in the form of resources –Sources of specific information, –Referenced with a global identifier (e.g., a URI in HTTP). Components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) –exchange representations of these resources (the actual documents conveying the information). Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request –an application can interact with a resource by knowing two things: the identifier of the resource and the action required –no need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and resource –The application need to understand the format of the information (representation) returned.

21. 21 REST Architectural Constrains (1) Client-server –Separation of concerns –Networking –Independent evolution Layering –Composability Stateless communication –Scalability, reliability –Resources are stateful (stateless = no session)

22. 22 REST Architectural Constrains (2) Uniform Interface –Simplicity (vs. efficiency) –Large-grained hypermedia data transfer –Example: Create, Retrieve, Update, Delete Caching –Efficiency, scalability –Consistency issues Code-on-demand –Extending client functionality

23. 23 RESTfulness Criterion for Web applications: 1.Using the uniform interface –Using safe interactions 2.Hypertext drives the application 3.Cacheability 4.Statelessness –Often over-generalized, misunderstood

24. 24 Safe Interactions No obligations incurred Safe  idempotent (not vice versa) HTTP GET is safe Can be used opportunistically –E.g. link pre-fetching, crawling Unsafe does not mean dangerous Applications with unsafe GETs may get undesired effects

25. 25 Hypermedia Links between resources –Not only, also forms Also applies to machine-oriented data: XLink, XForms –Allow further actions That means all of GET, POST, PUT, DELETE –GETs can be bookmarked Client navigates the graph –May discover new links at every step –Can always do GET retrieval without worries –Can go back in browsing/state history Which does not undo the action(s)

26. 26 Example: Hotel Booking Hotel booking service service description search results hotel info confirmationmy bookings payment

27. 27 Hotel Service Workflow 1.Retrieve service description 2.Submit search criteria according to description 3.Retrieve linked details of interesting hotels 4.Submit payment details according to selected rate description 5.Retrieve confirmation of booking 2b.Retrieve list of user's bookings

28. 28 Hypermedia  Operations search(date, city)  list of hotels & rates getHotelDetails(hotel) reserve(rate, creditCard)  confirmationID getConfirmationDetails(confID) listMyBookings()  list of confirmationIDs nouns vs. verbs

29. 29 Hypermedia  Operations Hypermedia is a UI paradigm In REST, hypermedia is the "engine of application state" Programmatic clients work with operations Operation available when the client has the link

30. 30 TECHNICAL SOLUTION Current “REST-Like” Web Services

31. 31 Flickr Not RESTful The client must know all methods beforehand –Out-of-band information drives the interaction instead of hypertext Non-standard authentication, tokens in URI –More out-of-band information on forming URIs URIs with method name identify verbs (operations), not nouns (data) –Instead of "DELETE URI " it has "POST nothing to URI "

32. 32 Not RESTful, So What? Disadvantages of not being RESTful: 1.Client specific to an application A different photo app  client rewrite 2.No generic client can use the API Cannot navigate with your browser from a different Web site directly to add a contact Preventing seredipitous reuse Simply, the API not "on the Web"

33. 33 TECHNICAL SOLUTION Describing and consuming RESTful services

34. 34 Describing RESTful Services Machine-readable descriptions useful –Tool support for developing clients –Service discovery There's no WSDL for Web apps –APIs described mostly in text –AtomPub has RFC, Service Documents –Resources behind AJAX stay undescribed Some machine-readable descriptions: –HTML links, forms –AtomPub service document –WADL

35. 35 Textual Descriptions "There's usually an HTML page" –E.g. the Flickr documentation Such text can be annotated –hRESTS, MicroWSMO (Class 10)

36. 36 Example Description flickr.contacts.getList Get a list of contacts for the calling user. Authentication This method requires authentication with 'read' permission. Arguments api_key (Required) –Your API application key. filter (Optional) –An optional filter of the results. from http://www.flickr.com/services/api/flickr.contacts.getList.html

37. 37 WADL Web Application Description Language –Proposed by Marc Hadley (SUN), no real uptake (yet?) Application ( = our Web service) –Has resources –Resources have HTTP methods –Inputs and outputs can contain liks to resources WADL focuses on resources and hypertext –As opposed to operations (WSDL)

38. 38 JSON Overview JavaScript Object Notation –RFC 4627, json.org Simple alternative to XML –Used by a growing number of services –Especially Javascript-friendly, good for AJAX A serialized object or array –No namespaces, attributes etc. –No schema language (for description)

39. 39 JSON Example { "Image": { "Width": 800, "Height": 600, "Title": "View from 15th Floor", "Thumbnail": { "Url": "http://www.example.com/image/481989943", "Height": 125, "Width": "100" }, "IDs": [116, 943, 234, 38793] }

40. 40 AJAX Asynchronous JavaScript and XML (AJAX) –A group of interrelated web development techniques used on the client- side to create interactive web applications Constituent technologies –(X)HTML and CSS for information styling and marking –Document Object Model (DOM) accessed through JavaScript –Method to exchange data between the server and browser in async manner (XMLHttpRequest object) –Data formatting (XML or JavaScript Object Notation - JSON) –Binding technology (e.g., Java Script) AJAX is used to increase interactivity and dynamism of web pages Since the technological base is partially shared AJAX and RESTful services make a good match –Enriching Web pages with the data operated through RESTful services

41. 41 TECHNICAL SOLUTION A u t h e n t i c a t i o n C o n s i d e r a t i o n s

42. 42 Authentication in General Most "REST-like APIs" have proprietary authentication mechanisms Plus mandatory API keys for applications –But a user with a browser needs no API key –Web sites cautious of overload, abuse –Conflict between openness and control

43. 43 Authentication: Flickr API Application needs an API key –API key requested by application developer –Application has a shared secret with Flickr Every method needs API key Application lets user log in, gets auth token Authenticated methods need auth token and signature –Signature uses shared secret and all parameters More at http://www.flickr.com/services/api/misc.userauth.htmlhttp://www.flickr.com/services/api/misc.userauth.html

44. 44 EXAMPLES

45. 45 Example RESTful Services Atom Publishing Protocol Flickr API

46. 46 Example: AtomPub Protocol Atom: a collection (feed) of entries Collection resource –GET: list entries –POST: add an entry Entry resource(s) –GET: retrieve –PUT: replace/update –DELETE: delete collection entry URIs service

47. 47 Example: Flickr Example operations (methods): –flickr.photos.addTags –flickr.photos.delete –flickr.contacts.getList –flickr.photos.comments.editComment –… HTTP GET or POST @ http://api.flickr.com/services/rest/?method= method &parameters Special authentication method

48. 48 SUMMARY

49. 49 RESTful Services Summary Natural development of the Web –Rich AJAX UIs need back-end services –Sites make it easy for users to contribute (using external tools) Real RESTful services integrate well with the Web –Not many well-known APIs actually RESTful Using HTTP, XML, JSON

50. 50 Further Developments Describing RESTful services –hRESTS like a simplified WSDL –MicroWSMO adds semantic annotations Analyzing Javascript in AJAX sites –Could extract information about the services Expect more openness

51. 51 References Mandatory reading: – Further reading: –HTTP: http://tools.ietf.org/html/rfc2616http://tools.ietf.org/html/rfc2616 Wikipedia links: –Web 2.0: http://en.wikipedia.org/wiki/Web_2.0http://en.wikipedia.org/wiki/Web_2.0 –REST: http://en.wikipedia.org/wiki/RESThttp://en.wikipedia.org/wiki/REST –JavaScript: http://en.wikipedia.org/wiki/Javascripthttp://en.wikipedia.org/wiki/Javascript –AJAX: http://en.wikipedia.org/wiki/AJAXhttp://en.wikipedia.org/wiki/AJAX –JSON: http://en.wikipedia.org/wiki/JSONhttp://en.wikipedia.org/wiki/JSON –Atom: http://en.wikipedia.org/wiki/Atom_(standard)http://en.wikipedia.org/wiki/Atom_(standard –Mashups: http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid) http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

52. 52 Next Lecture #Title 1Introduction 2Web Science 3Service Science 4Web services 5Web2.0 services 6Semantic Web 7Web Service Modeling Ontology (WSMO) 8Web Service Modeling Language (WSML) 9Web Service Execution Environment (WSMX) 10OWL-S and other 11Light-weight Annotations 12Applications 13Mobile Services

53. 53 Questions?