A number of approaches combine the principles and technologies of Linked Data and RESTful services. Services and APIs are thus enriched by, and contribute to, the Web of Data. These resource-centric approaches, referred to as Linked APIs, focus on flexibility and the integration capabilities of Linked Data. We use our experience in teaching students on how to use Linked APIs to identify the existing challenges in the area. Additionally we introduce the LAPIS catalogue, a directory for Linked APIs as basis for the research to address the identified challenges.
According to the Richardson maturity model [
The idea behind REST is that applications, i.e., clients, using functionalities provided on the web, i.e., APIs, are not based on the call of API-specific operations or procedures but rather on the direct manipulation of exposed resource representations or the creation of new resource representations. A resource can be a real world object or a data object on the web. The representation of a resource details the current state of the resource. A manipulation of the state representation can imply that the represented resource is manipulated accordingly.
The flexibility of REST results from the idea that client applications do not have to know about all necessary resources. The retrievable representation of some known resources contains links to other resources that the client can discover during runtime. Clients can use such discovered resources to perform further interaction steps.
The Linked Data design principles1 also address the use of URI-identified resources and their interlinkage. However, Linked Data is so far only concerned with the provisioning and retrieval of data. A combination of Linked Data with REST architectures is therefore an intuitive extension, to offer flexible functionality with easy data integration capabilities. In contrast to REST, Linked Data does distinguish explicitly between URI-identified objects (i.e., non-information resources) and their data representation (information resources). An extension of Linked Data with REST to allow for resource manipulation leads to read/write Linked Data, i.e., information resources can be accessed and manipulated. REST furthermore implies that a change of an information resource can result in a change of the corresponding non-information resource.
The extension of Linked Data with REST technologies has been explored [
Linked APIs consider how the data that results from computation over input can
carry explicit semantics. Many approaches base their service descriptions on the notion
that Linked Data already provides a description for services’ input and output
requirements: the graph patterns provided by the SPARQL query language or the N3 notation
[
Increased value comes from combining data from multiple sources and functionality from multiple providers. Such combinations are fostered by the use of Linked Data, which enables an easy integration of the communicated data by the clients that use several Linked APIs. 3
We organised three seminars at the Institute AIFB where undergraduate students had to create applications based on Linked APIs. In total, we had 20 students that worked in groups of sizes between 2 and 4. The participating students had programming experience, but were relatively new to the field of Web APIs. Therefore the students are well suited to represent developers that consider using Web functionality for the first time. We collected the experiences made by the students to identify existing entry barriers of Linked APIs and derive key challenges that should be addressed by the research community to foster the adoption of the existing approaches.
Each student was tasked over the course of 4 months to develop at least one Linked Data-based REST API and to develop an application that makes use of at least two such APIs by integrating their data and composing their functionality. The students were allowed to leverage existing (not Linked Data-based) REST APIs for the development of a Linked API by wrapping them and offering their functionality as Linked API with the possibility for RDF data input and output. In the remainder of this paper we refer to the used pre-existing non-Linked Data APIs as underlying APIs.
At the end of the 4 months the students wrote a report about their experiences and lessons learned when working with Linked APIs. Since the students were not given a list of predefined answers, we clustered the problems (Table 1) as well as the perceived benefits when working with Linked APIs the students reported. Even though the collected experiences of the students can not be seen as a representative survey, they provide empirical indicators to existing problems in the field of Linked APIs, which imply important challenges that should be addressed by the research community. Many participants mentioned similar problems in their reports, which supports the claim that we identified recurring issues.
One of the two most common reported problems was with regard to the response time of composed APIs (reported by 14 students). The slow response time of composed APIs could be on the one hand attributed to slow response times of underlying APIs that were used by the students. On the other hand the interaction between APIs was also a significant factor: A single call to a composed API could potentially result in hundreds of subsequent calls to the different Linked APIs, that had to be sequentially executed, thus causing significant delays before the initial call could be answered. We see one of the most important challenges for the research in the area of Web APIs in the development of methods to achieve a scalable interaction with APIs. This includes the definition of interaction models on which applications can build upon as well as systems to enable the combination and composition of offered functionalities. The quick identification of APIs that have to be called next within a defined interaction pattern, as well as the ability to identify sets of API calls that can be executed in parallel are crucial factors to address this challenge.
API limitations refer to reported problems originating from limitations, insufficient
functionality and constraints of the underlying APIs (e.g., a maximum number of API
calls per day or incomplete data). While these limitations are usually driven by external
circumstances (e.g., business aspects), it is noteworthy, that 10 out of the 14 participants
that reported to have such problems considered to use different APIs than originally
intended because of the limitations. However, these participants reported problems
identifying suitable APIs as a replacement. APIs often need to fulfill very specific (functional
and non-functional) needs to allow developers to fulfill their goal when
implementing web-based applications. Since the functionality of many web APIs is often only
described with natural language texts, the task of finding a suited API for a specific
problem is often carried out by trial and error. However, a trial and error approach does
not allow to consider hundreds of potential candidates for a Web API. In addition to
application developers, the identification of APIs with specific functionalities is also
important for API providers. Since REST demands an interlinkage of API resources
(potentially from different providers) and the usefulness of an API is increasing with
these links, the task of finding related APIs becomes crucial for API providers to
include their API in an ecosystem of APIs on the web. Many approaches to Linked APIs
propose to leverage graph patterns to provide machine-readable descriptions of
functionality and properties to mitigate the problem [
Even though many of the participants used the possibility to describe Linked APIs with graph patterns, 8 participants had difficulties because they could not identify a definitive formalism for the descriptions (No standard formalism for API descriptions). Indeed, the research community should make an effort to define a common standard way of describing APIs, especially since most existing description mechanisms are already based on the same notion of utilising graph patterns. Such a standard should include a vocabulary for the description, a clear definition of the minimal set of properties that are to be described (e.g., input and output data), and a standard way of attaching a description to an API resource (e.g., retrievable via the HTTP OPTIONS method). The common description would not have to cover all possible aspects that can be described, but should be flexible enough to allow for extensions to cover the specific needs of the individual Linked API approaches. Merely the aspects that are necessary to invoke the operations on the API resources have to be described in a unified way to foster the adoption of Linked APIs by developers.
Related to the problem of finding replacements for APIs, the participants also reported they were often not able to identify suitable information on where to find existing Linked APIs (reported by 12 participants). We classified these problems as missing directories. While this is not a research problem per se, we believe it is a fundamental issue to be addressed not only to enable research on the topic, but also to foster the adoption of Linked APIs by application developers (cf. Section 4).
Finally, three students reported that the complexity of RDF was too high to be useful. However these three participants reported similar problems with other data formats like XML or JSON. Therefore there problems can be attributed to lacking development experience especially with web technologies.
Summarising we identified the following challenges that have to be addressed: – A common standard minimal description mechanism for Linked APIs based on graph patterns. – Methods for an automated identification and comparison of functional and nonfunctional properties that leverage the descriptions. – The development of methods and systems to enable a scalable interaction and composition of Linked APIs.
While these challenges remind of the high level tasks that have been addressed in
traditional web service research [
their Linked APIs. The LAPIS catalogue is based on CKAN4, an open-source data portal software, developed by the Open Knowledge Foundation 5. The objective of CKAN is to make it easy to publish, share and find data. It provides a powerful database for cataloguing datasets, with an intuitive web front-end and API.
Linked APIs can be registered in the LAPIS catalogue along with basic information like name, URI, author, license and maintainer. Additionally information can be provided about the supported content types, other APIs that are linked and underlying APIs, if the registered API is based on a wrapper. Due to the focus of CKAN on datasets, the registered APIs can be seen as Read/Write Linked Datasets (i.e., dynamic datasets that support more than one HTTP method for manipulation of the resources).
The LAPIS catalogue serves as hub for Linked APIs, where researchers, developers and API providers can find existing APIs to use in their individual tasks. Researchers in the field of Linked APIs can find relevant APIs for evaluation of their individual approaches (e.g., for interaction with APIs) or use the directory to survey the current developments and the adoption of their approaches (e.g., description mechanisms). Developers of applications based on Linked APIs can search and lookup APIs that can be employed in their applications. API Providers can use the LAPIS catalogue to promote their API for public use. However, also the directory of other Linked APIs can be useful for API providers: Since REST demands the interlinkage of resources, API providers require information about existing APIs to link their APIs to other resources and thus complementing the offered functionality.
Related popular directories are The Data Hub6 and Programmable Web7.
The Data Hub is a general directory for datasets that also provides information about links between datasets. While Read/Write Linked Datasets can be entered in The Data Hub, the much broader focus prevents The Data Hub to serve all the needs of the Linked API community. Specifically the tedious task of identifying the subset of registered datasets that support resource manipulation consistently with REST renders The Data Hub insufficient as an API repository. The related Linking Open Data cloud8 even explicitly excludes datasets that are served by a service that produces RDF in response to input data, which is an inherent property of Linked APIs.
Programmable Web is a directory for Web APIs and is therefore more focused on the functionality aspect compared to The Data Hub. Similar to The Data Hub, Linked APIs can be registered with Programmable Web along with other kinds of APIs and web services (e.g., SOAP-based services). However, the lacking focus on resource-centric interlinked APIs results in missing relevant information for developers and providers that work with Linked APIs. Specifically lacking information about links between the registered APIs is a significant problem in that respect.
The LAPIS catalogue is not a competitor of The Data Hub or Programmable Web, but a complementing directory between them. Therefore it is specifically targeted at – Read/WriteLinked Datasets (from the viewpoint of The Data Hub) or
– Linked Data-based REST APIs (from the viewpoint of Programmable Web), providing the relevant information from both areas. We will continue to maintain the LAPIS catalogue to foster the establishment of a pervasive web of Linked APIs. 5
In this position paper we sketched the main challenges for Linked APIs that need to be addressed to foster the adoption of Linked Data based REST APIs. We described the main problems in the work with Linked APIs from our experience when introducing students in the field and identified key topics as basis for discussion and further research. We believe, that the benefits that result from the combination of Linked Data and REST architectures are worth the effort to overcome the existing problems.
To foster the adoption of Linked APIs and research activities we introduced the LAPIS catalogue, an open directory for Linked APIs. A directory targeted at Linked APIs is an essential support mechanism for the uptake of Linked APIs and a fundamental requirement to intensive the research activities in the area.
This work was partially supported by the PlanetData NoE (FP7:ICT-2009.3.4, #257641) and by the German Ministry of Education and Research (BMBF) within the SoftwareCampus project framework.