ICWE 2015 - REST Web Service Description for Graph-Based Service Discovery
•Descargar como PPTX, PDF•
2 recomendaciones•1,066 vistas
This document proposes a REST API Description (RAD) for describing REST web services in a machine-readable graph-based format. RAD uses a hypermedia-centric metamodel to connect similar services semantically and facilitate automatic discovery and composition of REST services. The document demonstrates RAD implementations in JSON and Microdata and provides examples of discovering and composing services using the RAD graph through SPARQL queries. Future work includes improving automatic service composition and developing natural language queries for the RAD graph.
Recomendados
Recomendados
Más contenido relacionado
Similar a ICWE 2015 - REST Web Service Description for Graph-Based Service Discovery
Similar a ICWE 2015 - REST Web Service Description for Graph-Based Service Discovery (20)
Último
Último (20)
ICWE 2015 - REST Web Service Description for Graph-Based Service Discovery
- 1. REST Web Service Description for Graph-Based Service Discovery ICWE 2015 Authors: Rosa Alarcón Rodrigo Saffie Nikolas Bravo Javiera Cabello 25th June 2015 Pontificia Universidad Católica de Chile Engineering School Computer Science Department
- 2. Outline 1. Motivation & Problem Statement 2. Related Work 3. Rest API Description (RAD) 4. Results 5. Summary & Future Work Outline REST Web Service Description for Graph-Based Service Description
- 3. MOTIVATION AND PROBLEM STATEMENT Motivation REST Web Service Description for Graph-Based Service Description
- 4. Motivation • Let's suppose we want to create a service where you can look up your favorite artist's top tracks • Web services will allow us to use what others have already done • So how would we proceed to create such service? Motivation REST Web Service Description for Graph-Based Service Description
- 5. Motivation Motivation REST Web Service Description for Graph-Based Service Description
- 6. Motivation Motivation REST Web Service Description for Graph-Based Service Description
- 7. Motivation Motivation REST Web Service Description for Graph-Based Service Description
- 8. Motivation Motivation REST Web Service Description for Graph-Based Service Description
- 9. Motivation Motivation REST Web Service Description for Graph-Based Service Description
- 10. Motivation • Manual search of web services by category is insufficient • Descriptions are not machine-readable • Similar services are not connected Motivation REST Web Service Description for Graph-Based Service Description
- 11. REST WS Popularity Motivation REST Web Service Description for Graph-Based Service DescriptionSearchInterest Source: Google Trends, June 10, 2015
- 12. REST WS Popularity Motivation REST Web Service Description for Graph-Based Service Description Source: ProgrammableWeb, Mar 24, 2014
- 13. Problem Statement • Nowadays REST services are isolated • We aim for automatic discovery and composition of REST Web Services – Facilitate that end-users find the resources they need – Facilitate the creation of new services upon existing services Problem Statement REST Web Service Description for Graph-Based Service Description
- 14. RELATED WORK Related Work REST Web Service Description for Graph-Based Service Description
- 15. Related Work • RAML – http://raml.org/ • RESTdesc – http://restdesc.org/ • HYDRA – http://www.markus-lanthaler.com/hydra/ • WADL – http://www.w3.org/Submission/wadl/ Related Work REST Web Service Description for Graph-Based Service Description
- 16. REST API DESCRIPTION (RAD) RAD REST Web Service Description for Graph-Based Service Description
- 17. Rest API Description (RAD) • Hypermedia-centric • Machine-readable description • Connection of services at a semantic level RAD REST Web Service Description for Graph-Based Service Description
- 18. RAD Metamodel RAD REST Web Service Description for Graph-Based Service Description
- 19. RAD Implementations • RAD can be implemented in multiple formats • We used: – Microdata – JSON RAD REST Web Service Description for Graph-Based Service Description
- 20. RAD Implementations: JSON RAD REST Web Service Description for Graph-Based Service Description
- 21. RAD Implementations: JSON RAD REST Web Service Description for Graph-Based Service Description
- 22. RAD Implementations: JSON RAD REST Web Service Description for Graph-Based Service Description
- 23. RAD Implementations: JSON RAD REST Web Service Description for Graph-Based Service Description
- 24. RAD Metagraph RAD REST Web Service Description for Graph-Based Service Description
- 25. RESULTS Results REST Web Service Description for Graph-Based Service Description
- 26. An Illustrative Example • Spotify – https://developer.spotify.com/web-api/ • Songkick – http://www.songkick.com/developer • Uber – https://developer.uber.com/ Results REST Web Service Description for Graph-Based Service Description
- 27. Extended Vocabulary • Extended schema.org vocabulary • Parameters and actions have an URI • Specialization relationships between concepts Results REST Web Service Description for Graph-Based Service Description
- 28. Graph Results REST Web Service Description for Graph-Based Service Description
- 29. Results REST Web Service Description for Graph-Based Service Description
- 30. Results REST Web Service Description for Graph-Based Service Description Vocabulary
- 31. Use Cases • We will analize two use cases: – Service Discovery – Service Composition Results REST Web Service Description for Graph-Based Service Description
- 32. Use Case: Discovery A user wants to find a given artist’s playlists Results REST Web Service Description for Graph-Based Service Description ,
- 33. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 34. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 35. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 36. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 37. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 38. Use Case: Discovery Cypher Query Results REST Web Service Description for Graph-Based Service Description MATCH (concept)<-[:`is a`]-(resources)-[action]->(operations)-[:uses]->(parameters) WHERE concept.GRI=~ 'http://schema.org/Thing/CreativeWork/MusicPlaylist.*' AND action.GRI = 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction' AND concept: `Resource Concept` AND resources: Resource AND operations: Operation AND parameters: Parameter RETURN concept, resources, operations, parameters
- 39. Use Case: Discovery Results REST Web Service Description for Graph-Based Service Description Concept: 'http://schema.org/Thing/CreativeWork/MusicPlaylist’ Action: 'http://schema.org/Action/GetAction/GetMusicRecordingCollectionAction’
- 40. Use Case: Composition A user wants to attend a concert but her favorite band is not in town. She decides to go to a similar artist concert and needs to know the venues where they will play as well as information of taxis to reach the event. Results REST Web Service Description for Graph-Based Service Description
- 41. Use Case: Composition Results REST Web Service Description for Graph-Based Service Description
- 42. Composition Results REST Web Service Description for Graph-Based Service Description Concept: ‘(…)/MusicGroupCollection’ Action: ‘(…)/GetSimilarArtistsAction’
- 43. Composition Results REST Web Service Description for Graph-Based Service Description Concept: ‘(…)/MusicEventCollection’ Action: ‘(…)/MusicEventSearchAction’
- 44. Composition Results REST Web Service Description for Graph-Based Service Description Concept: ‘(…)/TaxiCollection’ Action: ‘(…)/GetTaxiCollectionAction’
- 45. SUMMARY & FUTURE WORK Summary REST Web Service Description for Graph-Based Service Description
- 46. Summary • Natural language descriptions are insufficient for automatic discovery & composition • A hypermedia-centered model facilitates discovery & composition Summary REST Web Service Description for Graph-Based Service Description
- 47. Summary • A graph-based solution allows to represent links between REST web services • RAD allows resources and operations to be discovered through concepts and actions Summary REST Web Service Description for Graph-Based Service Description
- 48. Future Work • Automatic service composition • Metalanguage for RAD graph queries • Natural language queries Future Work REST Web Service Description for Graph-Based Service Description
- 49. Acknowledgements • Engineering’s Graduate School at PUC • Computer Science Dept. at PUC Future Work REST Web Service Description for Graph-Based Service Description
- 50. REST Web Service Description for Graph-Based Service Discovery ICWE 2015 Authors: Rosa Alarcón Rodrigo Saffie (rasaffie@uc.cl) Nikolas Bravo (ngbravo@uc.cl) Javiera Cabello 25th June 2015 Pontificia Universidad Católica de Chile Engineering School Computer Science Department
- 51. Extended Ontology Results REST Web Service Description for Graph-Based Service Description
- 52. Template • Blah Template REST Web Service Description for Graph-Based Service Description
Notas del editor
- So this will be the outline for our presentation
- So let’s start with an example: let’s suppose I want to create a new service that where I can look up the current top-tracks, amongst various rankings, of my favorite musical artist There exist some Web Services that could provide individual rankings of the artist’s top-tracks. We should consume such services. So how would we proceed to create such service?
- One would normally head into a API repository, such as Programmable Web. As we are searching for a service wich provides music information, we search by the music category.
- Let us note that, as humans, we are able to know that top-tracks is part of the Music category, but a machine can not. As a result be obtain numerous services with a very vague description of what they provide.
- We tumble into Spotify, a name we are familiar with and we hope can provide us what we need Still, the description is insufficient, so we must inspect the official documentation
- Now in the Spotify documentation, which has it’s own layout and format, we can check the list of resources they offer Among them we finally find /top-tracks, which seems to be what we were looking for So let’s check it out
- Entering the resource description we can see all the details we need to consume it: The URI The parameters The response template And an example Let’s note that this is one of the best descriptions we found. Also, we found this resource solely because of the resource name: top-tracks. Had it had another name, or one we didn’t understand we would not have found it.
- Searching by category is insufficient, as a category is not enough to describe the provided service Descriptions are heterogeneous made for human developers to read, and a machine can not make sense out of them. Similar services are not connected in a machine-understandable way.
- So why REST Web Services? Substantial growth in the last few years, probably because of properties such as: Low barriers of entry for developers High scalability due to statelessness Lightweight High evolvability
- We can also observe that REST is the predominant type of API in Programmable Web
- So what is the problem we aim to solve?: Nowadays REST WS are isolated, as machines are not able to create links between them We aim for automatic discovery and composition of REST Web Services. Why? This will facilitate that end-users find the resources they need And will facilitate the creation of new services upon existing services
- Some examples come from the industry: RAML (widely used), Swagger, Blueprint. Simple descriptions for REST API’s promoting best practices, bit they do not allow the discovery of services. Anothers from academic research efforts: RESTdesc: Requires a high level of understanding of RDF, which most developers do not possess. HYDRA Is similar, but many options they specify we consider not to be necessary. Additionally, they also dictate rules on how the service must be constructed. WADL: Equivalent to SOAP’s WSDL. It is operation-centric, as opposed to REST’s resource-orientation. The W3C has no current plans to standardize it.
- So we present RAD
- It is a Hypermedia-centric, machine-readable and understable description It allows the connection of services at a semantic level
- The previous model can be represented in different formats. For instance, we used Microdata and JSON.
- This is an example of Spotify API represented in RAD. There is general information of the service (for example baseURI) and a list of its resources.
- Inside each resource there is a reference to the concept that represents it, and a set of the HTTP operations that can be applied.
- Inside each operation there is a reference to the action it represents, and the list of parameters needed to invoke it.
- Descriptions are parsed into a single graph. The structure of this graph is as follows: Resource -> Operation -> Parameter -> Response Resource Concept -> Parameter Concept
- To validate our approach, we create an example using 3 real APIs: Spotify provides access to its music streaming service’s catalogue Songkick provides access to a live music database with information about upcoming and past concerts as well as setlists. Uber allows the user to ask for transportation service types, price and an estimated time of arrival
- For example, we used schema.org as vocabulary. Our model is independent of the selected vocabulary, as long as each concept has a unique identifier.
- Traverses the graph.
- Defines concept to be searched.
- What action to be executed over that concept.
- And some basic restrictions over the node’s types.
- And return the result of the query.
- We observe two services provide what we need: Songkick: provides a concert’s setlist Spotify: provides an artist’s top tracks
- First we execute a query to find how to GET a COLLECTION of SIMILAR ARTISTS. Two resources return what we need, one from Spotify and one from Songkick
- Then, with the result of the previous query, we SEARCH for EVENTS for those artists. In this case we find 7 resources that provide such information.
- Finally, we wish to get information about taxis to get to the venue of the concert. We find a single resource provided by Uber.
- - 2do punto: “not just the service as a whole”
- Currently we only find the composition workflow. In the future we aim to make the execution of this workflow automatic. As we have seen, CYPHER queries are not user-friendly, and expose too much of the underlying graph. We are working on creating a metalanguage for querying RAD graphs. We also will work on natural language queries, making this tool friendly for those who wish to discover services.