Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Framework for Self-descriptive RESTful Services


Published on

The Fourth International Workshop on RESTful Design, WS-REST 2013
A framework for self-descriptive RESTful services
Luca Panziera and Flavio De Paoli

Published in: Technology, Education
  • Be the first to comment

A Framework for Self-descriptive RESTful Services

  1. 1. A Framework forSelf-descriptive RESTful ServicesLuca Panziera and Flavio De Paoli{panziera, depaoli}@disco.unimib.itUniversity of Milan-BicoccaDISCo – Department of Computer Science, Systems and CommunicationITISlab - Innovative Technologies for Interaction and ServicesWS-REST 2013 - Fourth International Workshop on RESTfulDesign@ WWW2013, 14 May 2013, Rio de Janeiro, Brazil
  2. 2. Service descriptions Descriptions allow for service discovery Automatic discovery require service descriptionsaccording to a common model Several (semantic) models and languages havebeen proposed to describe services: WSDL 2.0 WADL MicroWSMO hRESTS SA-REST etc. Very few descriptions are actually available on theWebNo one is a de facto standard
  3. 3. Web APIs Most of the existing services provide Web APIs: Use of HTTP to tunnel procedure calls Unknown semantics of both operations and exchangeddata
  4. 4. Real service descriptions Most services are RESTful services/Web APIs Real information about services is available through: Provider documentation Web API repositories (e.g., ProgrammableWeb) Performance monitoring services(e.g., API-status, Watchmouse) Social media (wikis, blogs, forums, Q&A sites) Information is available in: HTML, PDF, … (natural language) XML JSONHeterogeneous unstructured descriptions
  5. 5. Current discovery practiceI need a music repository withdata under a free licenseResults“music repository with data under a free license”WHAT?!Ineffective Discovery!
  6. 6. Goal: Description as a Service (DaaS) RESTful descriptions for self-descriptive services Descriptions as resources Enabling effective discovery by humans and machines The approach Definition of techniques for delivering self-descriptiveservices by extracting and publishing descriptions fromheterogeneous Web sources. Development of Web-based tools Definition of best practices for description management
  7. 7. DiscoveryEngineA new scenarioI need a music repository withdata under a free licenseRequest:Tags: “musicrepository”Data License: “Free”Self-descriptive services by extractinginformation from the WebDiscovery engines retriveself-descriptions as resourcesDiscovery of additionalinformationDiscogs:Tags:“music repositorydiscography”Data License:“Creative Commons”
  8. 8. REST in a nutshell Principles Identification of resources (URIs) Manipulation of resources through representations(HTTP Methods) Self-descriptive messages (Internet Media Types) HATEOAS (Hyperlinks) Advantages Data format and model independence Support for discovery of resources More “lightweight” compared to SOAP Compliancy to the nature of the Web
  9. 9. Problems to support discovery REST Limits: Data format and model independence Discovery engines require descriptions according to a commonmodel Lack of de facto standards for implementing HATEOAS Then, for discovery of service information as resources Web Document Limits Heterogeneous data formats and models Lack of a shared vocabulary for service properties E.g., functionalities, licensing, QoS, service rating, usagefees, etc.The Solution: Definition of best practices for DaaS
  10. 10. BP1: Information modelling RESTful services need to be described according toa shared and formal model that species functionaland non-functional properties. The definition of a sound model for representingservice properties is fundamental manipulatedescriptions exploiting the same syntax andsemantics. Functional properties (FPs) define functionalities providedby a service Non-functional properties (NFPs) define servicecharacteristics that are not strictly related to thefunctionality E.g., licensing , QoS, usage fees, etc.
  11. 11. Implementing BP1: PCM-lite Lightweight Policy-Centered Meta-model Features: Simple and Lightweight model Data Format independece Expressiveness Specification of advanced operators Numeric intervals Set theory operators Specification of units ofmeasuraments
  12. 12. BP2: Semantic data model Data that describes service properties need to berepresented according to RDF. Semantic Web standards enable: Advanced evaluations (e.g., subsubtion, semantic equivalence) To address homonymy and synonymy of terms Adoption of domain ontologies as vocabularies
  13. 13. Domain ontologyImplementing BP2user:data_licensepcm-lite:hasValuelicense:Free_license .discogs:data_licensepcm-lite:hasValuelicense:Creative_Commons .Free_licenseCreative_CommonsGPLApacheis-ais-a is-aMatch!!!
  14. 14. BP3: Common vocabulary Property values should represent concepts that arelinked to concepts available on the Linking OpenData Cloud. Linking open data cloud refers to general-purposeontologies to represent a vast portion of humanknowledge Prevention of ambiguity, synonymy andhomonymy, and thus facilitating evaluations byautomatic toolsuser:data_licensepcm-lite:hasValuedbpedia:Free_license .discogs:data_licensepcm-lite:hasValuedbpedia:Creative_Commons .
  15. 15. BP4: Human interpretability A natural language description, or label, must beassociated with each service property. Pure RDF documents, without natural languagedescriptions, reduce human readabilitydiscogs:policy rdfs:comment “This document describes DISCOGS RESTful APIs”.discogs:policy pcm-lite:hasProperty discogs:tags .discogs:policy pcm-lite:hasProperty discogs:data_license .discogs:tags rdfs:comment“It reppresents a set of tags that summarize service functionalities” .discogs:tags pcm-lite:hasValue dbpedia:Music .discogs:tags pcm-lite:hasValue dbpedia:Respository .discogs:tags pcm-lite:hasValue dbpedia:Discography .discogs:tags rdfs:comment “The service data is under creative commons license” .discogs:data_license pcm-lite:hasValue dbpedia:Creative_Commons .
  16. 16. BP5: RESTful descriptions Services must provide descriptions as aggregationsof properties published as RESTful resources. HATEOAS is implemented trough links according toLinked Data@prefix discogs: <>discogs:policy rdfs:comment “This document describes DISCOGS RESTful APIs”.discogs:policy pcm-lite:hasProperty discogs:tags .discogs:policy pcm-lite:hasProperty discogs:data_license . pcm-lite:hasValue dbpedia:Music .discogs:tags pcm-lite:hasValue dbpedia:Respository .discogs:tags pcm-lite:hasValue dbpedia:Discography . pcm-lite:hasValue dbpedia:Creative_Commons .
  17. 17. A PCM-lite policy for the Foo service (1) The policy:@prefix : <>@prefix pl : <>...:fooPolicy rdf:type pl:policy.:fooPolicy rdfs:comment ”Foo is a REST API for ... ."@en.:fooPolicy rdfs:label "FooRESTAPI"@en. resources of the service:fooPolicy pl:hasProperty :resource1.:foopolicy pl:hasProperty :resource2.... non-functional properties:fooPolicy pl:hasProperty :datalicense.:fooPolicy pl:hasProperty :responsetime....
  18. 18. A PCM-lite policy for the Foo service (2) A functional property as a resource: resource1...@prefix dbpedia : <> rdf:type rdf:type pl:hasRelation....:resource1 rdf:type pl:property.:resource1 rdfs:comment “The 20 most recent mentions(tweets containing a userss @screen_name)for the authenticating user."@en.:resource1 pl:hasValue :statuses/mentions_timeline.:resource1 pl:hasMethod dbpedia:HTTPGET....
  19. 19. A PCM-lite policy for the Foo service (3) A non functional property as a resource: responsetime...@prefix dbpedia:<>...:responsetime rdf:type pl:property.:responsetime rdfs:label "Service response time"@en.:responsetime pl:hasOperator dbpedia:Less_than.:responsetime pl:hasValue "0.153”.:responsetime pl:hasUnit dbpedia:Second....
  20. 20. Making available real information asRESTful resoureces Self-description wrapper An additional moduleto service business logic Modelled as a RESTfulservice Messages of the maininterface are forwaredto the wrapper
  21. 21. Discogsdiscogs:licensepcm-lite:hasValuedbpedia:Creative_Commons .Process of property value extraction The approach is based on: Source-to-policy templates (S2PTs) Named entity recongnition (NER)S2PT:discogs:tagsdiscogs:licenseProgrammableWebdocument<pw:tags></pw:tags><pw:license></pw:license>“Under creative commons license”Dbpedia Spotlight(Named entity recognizer)
  22. 22. Scaling up Semantic Service Matchmaking22As of September 2010MusicBrainz(zitgist)P20YAGOWorldFact-book(FUB)WordNet(W3C)WordNet(VUA)VIVO UFVIVOIndianaVIVOCornellVIAFURIBurnerSussexReadingListsPlymouthReadingListsUMBELUK OpenLibrary(Talis) SECWikiUN/LOCODEUlmECS(RKBExplorer)RomaRISKSRESEXRAE2001PisaOSOAINSFNew-castleLAASKISTIJISCIRITIEEEIBMEurécomERAePrintsdotACDEPLOYDBLP(RKBExplorer)é-pédiaOrd-nanceSurveyOpenlyLocalThe OpenLibraryOpenCycOpenCalaisOpenEINewYorkTimesNTUResourceListsNDLsubjectsMARCCodesListMan-chesterReadingListsLoticoTheLondonGazetteLOIUSlobidResourceslobidOrgani-sationsLinkedMDBLinkedLCCNLinkedGeoDataLinkedCTLinkedOpenNumberslingvojLIBRISLexvoLCSHDBLP(L3S)LinkedSensor Data(Kno.e.sis)Good-winFamilyJamendoiServeNSZLCatalogGovTrackGESISGeoSpeciesGeoNamesGeoLinkedData(es)GTAASTITCHSIDERProjectGuten-berg(FUB)MediCareEuro-stat(FUB)DrugBankDisea-someDBLP(FUBerlin)DailyMedFreebaseflickrwrapprFishesof TexasFanHubzEvent-MediaEUTCProduc-tionsEurostatEUNISESDstan-dardsPopula-tion (En-AKTing)NHS(EnAKTing)Mortality(En-AKTing)Energy(En-AKTing)CO2(En-AKTing) In-cubator)ClimbingLinked Datafor PDBOMIMOBOMGIKEGGReactionKEGGPathwayKEGGGlycanKEGGEnzymeKEGGDrugKEGGCpdInterProHomoloGeneHGNCGeneOntologyGeneIDGenBankChEBICASAffy-metrixBibBaseBBCWildlifeFinderBBCProgrammesBBCMusicrdfaboutUS CensusMediaGeographicPublicationsGovernmentCross-domainLife sciencesUser-generated contentHeterogeneous sourcesRDF – Linked Open DataService repositoriesAPI finderService DescriptionsrequestBestSolution
  23. 23.  Discovery on PCM-lite descriptions is effective by the Policy Matchmakerand Ranker for Web (PoliMaR-Web) [1]. Some limitations for humans persist: RDF is less redable then HTML: poor tools for visualizzation Web browsers do not provide direct PUT and DELETE support to end-users Then, a Web app for managing descriptions is necessary[1] L. Panziera, M. Comerio, F. Palmonari, M. De Paoli, and C. Batini.Quality-driven Extraction, Fusion and Matchmaking of Semantic Web API Descriptions.Journal of Web Engineering, 11(3):247-268, 2012.Lesson Learned: Best practicesHTTP PUT
  24. 24. Lesson Learned: the Framework The extraction process suffers from potentialweaknesses Automatic generation of S2PTs is difficult Heterogeneous and unspecified schema of sources requiresmanual intervention any time the structure of a source changes Named entity recognition is not always successful Short textual documents may affect the techniqueExtractedPropertiesNER Precision NER RecallData formats 0.92 0.91Licensing 0.79 0.78Usage limits 0.45 0.61Avarage 0.72 0.77
  25. 25. Conclusions and future work Conclusions Self-descriptive services enable for more effectivediscovery for both humans and automatic tools Five best practices to exploit REST principles forproviding service descriptions Self-description wrappers to extract descriptions fromdisperse service information sources on the Web. Future Work Automatic construction of S2PTs Improve NER effectiveness Improve the interface of the tool to support effective userexperience
  26. 26. Thank you!Any questions?