[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Next Article in Journal
Information Quality Assessment for Data Fusion Systems
Next Article in Special Issue
A Sustainable Method for Publishing Interoperable Open Data on the Web
Previous Article in Journal
A Large-Scale Dataset of Barley, Maize and Sorghum Variety Identification Using DNA Fingerprinting in Ethiopia
Previous Article in Special Issue
Data for Sustainable Platform Economy: Connections between Platform Models and Sustainable Development Goals
You seem to have javascript disabled. Please note that many of the page functionalities won't work as expected without javascript enabled.
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Data
Volume 6
Issue 6
10.3390/data6060059
data-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles thumb_up
...
Endorse textsms
...
Comment
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

APIs for EU Governments: A Landscape Analysis on Policy Instruments, Standards, Strategies and Best Practices

by
Lorenzino Vaccari
1,†,
Monica Posada
2,*,†,‡,
Mark Boyd
3,† and
Mattia Santoro
4,†
1
Independent Researcher, 21017 Ispra, Italy
2
European Commission, Joint Research Centre (JRC), 21017 Ispra, Italy
3
Independent Researcher, 08004 Barcelona, Spain
4
Institute of Atmospheric Pollution Research-National Research Council of Italy (CNR-IIA), 50019 Sesto Fiorentino, Italy
*
Author to whom correspondence should be addressed.
†
These authors contributed equally to this work.
‡
The views expressed are purely those of the authors and may not in any circumstances be regarded as stating an official position of the European Commission.
Data 2021, 6(6), 59; https://doi.org/10.3390/data6060059
Submission received: 3 May 2021 / Revised: 28 May 2021 / Accepted: 29 May 2021 / Published: 8 June 2021
(This article belongs to the Special Issue A European Approach to the Establishment of Data Spaces)
Browse Figures
Figure 1
<p>Number of technical specifications and standards per category (source: authors’ elaboration based on [<a href="#B4-data-06-00059" class="html-bibr">4</a>]).</p> "> Figure 2
<p>API strategies maturity level (source: authors’ elaboration).</p> "> Figure 3
<p>Adoption of Web APIs. <b>Left</b> panel: cumulative count of the number of web API. <b>Right</b> Panel: cumulative count of the number of the most popular APIs by category (source: authors’ elaboration based on ProgrammableWeb.com data of June 2019 [<a href="#B4-data-06-00059" class="html-bibr">4</a>]).</p> "> Figure 4
<p>Types of APIs in analysed API cases (N = 219) (source: authors’ elaboration based on [<a href="#B79-data-06-00059" class="html-bibr">79</a>]).</p> "> Figure 5
<p>APIs classified by theme (N = 219) (source: authors’ elaboration based on [<a href="#B79-data-06-00059" class="html-bibr">79</a>]).</p> "> Figure 6
<p>APIs literature by topic and target level (N = 343) (Source: Authors’ elaboration, based on [<a href="#B79-data-06-00059" class="html-bibr">79</a>]).</p> ">
Versions Notes

Abstract

:
Application Programming Interfaces (APIs) could greatly facilitate the exchange of data and functionalities between software applications in a flexible, controlled and secure way, especially on the web. Private companies, from startups to enterprises, have been using APIs for several years now, but it is only recently that APIs have seen increased interest in the public sector. API adoption in the public sector faces organisational, technical, legal and economic obstacles, and to overcome these barriers, proposed methods from the private sector and early adopters in the public sector provide a way forward. The available documentation is often sparse, difficult to find and to reuse for new contexts. No past efforts to collect and analyse these resources have been made. To address this shortcoming, this paper describes a landscape analysis in four areas: the main European Commission policy instruments on the adoption of APIs, the available web API standards, a set of European government API strategies and cases, and a list of government proposed methods distilled from more than 3900 documents. Our results reveal that European policy legislation and associated instruments promote, and in some cases mandate, the use of APIs, and that governments’ API strategies in the European Union are rather young but also that there are well known web APIs standards and proposed methods ready to support the digital transformation of governments through rapid, harmonised and successful adoption of APIs.

1. Introduction

Technologies that enable the digital transformation of our society can give governments many opportunities, but they cannot be applied uncritically. Their application raises challenges that policy, research and practice must address with a strong and rigorous approach. One of these challenges is not to start adopting technologies in an ad-hoc manner, but rather, build IT strategies on a set of existing policy documents, standards and existing cases and good practices. This paper presents the results of our research on the adoption in governments of one relevant ICT technology: APIs.
The term ‘API’ is commonly used to refer to technologies that connect web applications but, indeed, APIs were known and used before the web era. An early definition of APIs appeared in 1968 when they were defined as ‘interfaces of various building blocks that application developers can assemble to create their products’ [1]. A more formal definition was given by [2] where the authors referred to APIs as ‘the calls, subroutines, or software interrupts that comprise a documented interface an application program can use the services and functions of another application, operating systems, network operating system, driver, or another low-level software program’.
Since then, almost 20 years have passed, and with the advent of the web, APIs have been heavily used by small and big companies (such as Amazon, Twitter, Facebook, Google, etc.) both internally and externally to develop digital business. Recently, due to the need to increase the efficiency of internal digital service delivery and to create digital ecosystems with many and diverse stakeholders, the public sector has also adopted and implemented APIs, in a similar way (but with different goals) to what occurred in the private sector, but both the adoption and implementation of APIs in governments across the European Union are still in their initial stage if compared with the experience of the private sector. It is true that, for more than ten years, the public sector has pushed and focused on the public sector information open publication and dissemination, thus obtaining a high level of transparency of government data, but it is also true that more efforts have to be made to make this information accessible and re-usable so that API users can build applications or share data in IT systems with other private and public institutions. APIs can play an important role in lowering these barriers, as is recognised by the European Commission in the Directive (EU) 2019/1024 on open data and the reuse of public sector information [3], which asks for mandatory use of APIs for High-Value Datasets (HVDs).
To support the Directive (EU) 2019/1024 and further policy legislative documents and instruments (See also Section 3.1), in 2018 the European Commission started the study on ‘Application Programming Interfaces for Digital Government’ (APIs4DGov) (Since 2020, a follow-up study ‘API for Innovative Public services’ (API4IPS) was started. The follow-up is a specific activity within the Innovative Public Service (IPS) action of the ISA 2 action. It is a collaboration between the JRC, the Directorate-General for Communications Networks, Content and Technology (DG CONNECT) and the Directorate of Informatics (DG DIGIT) of the European Commission.), undertaken by the European Commission Joint Research Centre (JRC) in partnership with the Directorate-General for Communications Networks, Content and Technology (DG CONNECT) of the European Commission. The APIs4DGov study aimed to answer two main questions: ‘Why should governments adopt APIs?’ And ‘How should governments do it?’.
To answer these questions, the need for a deep analysis of the API landscape in government emerged at the beginning of the study. This need motivated the work and the results illustrated in this paper. The main results of the study, concluded in April 2020, are illustrated in several reports supporting the adoption and implementation of APIs in governments [4,5,6]. This paper, in particular, illustrates a summary and an update of the work we have conducted in collecting, classifying and analysing information from a wide range of resources about the API landscape in governments.
The availability of existing documents and research on the API landscape in the public sector is sparse and difficult to find and reuse. No past efforts to research and analyse these resources has been made. Thus, we complemented our desk research with a set of structured methods by engaging various stakeholders (experts, representatives and practitioners from both the private and the public sectors) in the EU and beyond in interviews on specific case studies, focused workshops, surveys and discussions. These activities are illustrated in Section 2. Section 3 presents the results of our investigation, based on a set of documents gathered and analysed in four landscaping areas: an essential set of policy documents that propose or require the use of APIs in the public sector; a collection of web standards and technical specifications that are currently in use for the development of web APIs; a selection of government API strategies and representative cases that could help in understanding how APIs have been used and could be used at different administrative levels and in different domains; and an extensive list of proposed methods, guidelines and recommendations that, depending on the type of need and API maturity adoption, can be used as reference documentation by governments. Altogether, these outputs and related results form a solid knowledge base supporting governments in their API journey, as discussed in Section 4.

2. Materials and Methods

Our general methodology followed the indications of the ICT Impact Assessment Guidelines, developed within the ISA 2 programme of the European Commission [7]. The approach suggested by the guidelines represented a useful reference in choosing the best research methods (including desk research, workshops, surveys, interviews with experts and case studies) to reach the objectives of the study. We used them to gather and analyse data from several diverse sources and by engaging many stakeholders from the public and the private sector, including:
  • Government representatives and experts from our API case studies and benchmark [8].
  • The Digital Champions representatives of the EU, ambassadors for the Digital Single Market (DSM), appointed by their MSs [9].
  • The Interoperability of European Public Services expert group of Chief Information Officers [10].
  • The E-government action plan steering board [11] members.
  • The Open and Agile Smart Cities (OASC) coalition members [12].
  • The members of the APIdays community [13].
The use of this approach facilitated the cross-fertilisation of the information among different domains and let us validate our results by using both qualitative and quantitative analysis. A summary of our activities performed within this approach include:
  • A quantitative desk research analysis based on data collected from different resources, including the documents in the European Commission JoinUp platform [14], a set of APIs taken from diverse data catalogues and API registries (including the ProgrammableWeb directory, the European data portal and the European Union open data portal) and a set of API cases collected from previous studies on e-government and digital government at the EU level.
  • The analysis of the results of a series of online surveys we launched during the study: A first one, based on a semi-structured questionnaire [15], was focused on public-sector API strategies; and a second one, based on a structured questionnaire, was used to validate the API framework and recommendations we proposed at the end of the APIs4DGov study [16,17,18].
  • The analysis of the outputs of seven structured interviews on specific case studies [8,15,19].
  • A series of workshops focusing on the four landscaping areas presented in this paper:
    –
    A workshop, organised at the JRC premises in October 2018, on the main aspects of the public-sector API strategies in the EU [20].
    –
    A hackathon, organised as part of the INSPIRE 2018 conference, on API trends, standards and strategies in the geospatial domain [21].
    –
    Five workshops, organised within the APIdays series of conferences and events in 2019 and 2020 [22,23,24,25,26], focusing on API cases, standards and proposed methods.
Our specific activities for the analysis of the landscape of policy initiatives considered a set of regulatory documents and implementation collected from the official European Commissions web sites about the Digital Single Market (DSM) and policies, including the ones concerning the provision of data assets, public services, and the regulations in specific domains, such as the geospatial and the banking sectors APIs.
For the analysis of the landscape on API standards and technical specifications, we adopted an extensive desk research activity integrated, complemented and validated with information from our multiple case studies interviews [8], from the survey on API strategies and from a set of interviews to and presentations by API experts participating to our workshops, both from the private sector and the public sector.
From an initial long list of available standards and specifications, we distilled the ones specifically related to web APIs and classified them by ‘technical specification’ and ‘standard’ (We adopted the definition of these terms from the Open Geospatial Consortium (OGC)) [27], by functional use (design, security, usability, test, performance and licence), and by architectural style (Resource Procedure Call (RPC) and Representational State Transfer (REST)).
The analysis on API strategies and API cases was based on our desk research, the results of seven specific case studies in Europe [8], on a workshop [20] and a survey [28], both launched in 2018. The case studies were selected to cover a variety of criteria, including different levels of API strategy adoption (operational and strategic), different administrative levels (local, national and supranational), a geographic coverage both from the north and south of the EU and a range of sectors and public services. The workshop included keynotes from world-renowned experts from industry and academia, as well as contributions from API practitioners and representatives from governments at national, regional and local levels. With the survey, we explored three aspects, namely: the available API strategies at different levels of government, the implemented API cases in governments and the needs for European actions regarding APIs in the public sector. The survey questionnaire, formed of 130 questions related to each of these three aspects, was filled by 35 participants of which 14 at the National EU level. [28].
As the number of cases collected from events and the survey was insufficient to perform our analysis, we then investigated available research and methodologies to collect, automatically and systematically, additional API cases on the web. We found that past research has been conducted by IBM to automatically retrieve APIs but that it has been discontinued [29]. We also found that some experts and companies have investigated building API search engines, but discovered that these tools only work on their API registries [30,31,32,33]. Thus, we proceeded by listing the main API registries and resources on the web and by extracting from them a list of API cases we could use for our research:
  • The ProgrammableWeb API directory [32].
  • The database of 395 cases taken from the study “Towards faster implementation and uptake of open government (SMART 2015/0041)” [34].
  • The news web page provided as part of the DSM initiative entitled ‘Open eGovernment practices in all EU Member States make public services more collaborative, efficient and inclusive a useful list of relevant endpoints’ [35].
  • The European Union open data portal [36].
  • The European Data Portal (EDP) [37].
  • The INSPIRE geoportal [38].
Regarding the methodology used for the proposed methods landscape, we have conducted extensive work on the collection of the available documentation and the distillation of the relevant ones, followed by their classification. Initially, a set of 152 documents, coming from our workshops, surveys and case studies, were included in the proposed method literature review. From the analysis of these documents, a set of 39 keywords, illustrated in Table 1, were chosen. These keywords were then used to perform a systematic web search to add further literature to the initial set of documents.
Keyword searches were conducted from 1 March to 31 May 2019. The list of retrieved documents results was reviewed and only the documents created after 2014 and specifically related to or used by the public sector were selected. A total of 968 articles were sourced in this way, analysed and cleaned (to find duplication, not relevant documents, etc.). From this list, 343 articles were considered noteworthy and relevant to the study and classified by institutional type (public administration, academic, consortium or non-profit), individual authorship (expert, international organisation, journalist, private company), intended audience of the document (public sector, private sector or both), target level (strategic, organisational, operational), area (international, European, national, regional, city), source of the document (government GitHub repository, official publication, private sector, vendor white paper, journal paper, presentation, blog, website) and type (proposed methods(This type includes strategies, tactics and operational implementations that have been proven to have worked across multiple governments; in this analysis, the term ‘proposed method’ most closely aligns with RFC 2119’s use of the word ‘MUST’ [39]), guidelines(This refer to documents applied by some governments that have limited evidence of efficacy (as yet), or that represent some frontier approaches being taken by governments showing a more experimental innovation agenda based on existing proposed methods; in this analysis, the term ‘guidelines’ most closely aligns with RFC 2119’s use of the word ‘SHOULD’ [39]) and recommendations(Suggested or being tested by some governments, for which there is not yet strong evidence; these approaches represent frontier, experimental efforts; in this review, the term ‘recommendations’ most closely aligns with RFC 2119’s use of the word ‘MAY’ [39])).

3. Results

Based on the need to gather and analyse the API landscape for government in Europe, this study focused on the European policy context and main policy instruments, API strategies and cases in governments, API standards and API proposed methods useful for the public sector. The results of our investigation on each of these topics will be illustrated in the next sections.

3.1. API Landscape in European Policies

Europe aims at becoming a strong, competitive, sustainable and fair leader in the Digital Era. For achieving this goal, several European strategy documents highlight the importance of the creation of European data spaces and its proper governance, namely, the communication about Shaping EU’s digital future [40], the European Data Strategy [41], the European Industry Strategy [42] and the White paper on the uptake of Artificial Intelligence [43]. In this context, the policy relevance of APIs lies in their capacity to facilitate the sharing of data and functionality and the re-use of these assets by different actors and systems in data-driven ecosystems. This section analyses how APIs feature in this data sharing regulatory scene.
Starting with the European strategy for data, Europe has been a pioneer in regulating data-enabled environments. Example of already implemented legal acts are (i) the INSPIRE Directive on the use of geospatial data in the environmental domain [44]; (ii) the General Data Protection Regulation (GDPR) on the use of personal data [45]; and (iii) the Payments Service Directive (PSD2) on data use in the banking sector [46].
In these environments, APIs have a prominent role in sharing and re-using data, although implementation strategies vary. For instance, in INSPIRE, API adoption has been suggested [47,48] and endorsed [49]. In the GDPR context, API technological adoption is uneven, though APIs are used in implementation processes, such as user consent, data portability, the right to be forgotten and traceability. While not specifically defined in the legislation, API connections wire the implementation of PDS2. This environment has certainly reached the farthest in terms of the creation of API-enabled digital ecosystems [50].
Moreover, APIs play an explicit role in the Open Data and re-use of public sector information Directive, which is about to be rolled out [3]. This Directive mandates APIs to provide access to High-Value Data Sets (HVDs) to unlock the value of publicly held information through its re-use. Likewise, APIs will presumably play the same enabling role in implementing legal acts currently under definition. For instance, on the Digital Governance Act [51], the Digital Markets Act [52], the Digital Services Act [53], the Data Act and more to come.
Following with the European industrial strategy, the document stresses the need for a ‘partnership approach to the governance of industrial ecosystems’ to cross-fertilise products and services among sectors. In parallel to it, the Small and Medium-size enterprise (SME) strategy for a sustainable and digital Europe [54] mentions the need to ‘empower SMEs to reap benefits of the digital transformation’. In this context, APIs will enable the technical and organisational integration of actors and systems through the modulation of access to data and functionality. This connective role will be critical for fostering the innovation of industry (including SMEs).
Considering the European approach to artificial intelligence uptake, APIs will technically enable and thus empower businesses to start, scale up, innovate and compete on fair terms on AI applications. Specifically, AI applications rely on API infrastructure for (i) making data available to feed AI (e.g., access to training data), (ii) allowing access to infrastructure for computational distribution, and (iii) making access to underlying AI algorithms virtually unlimited.
Finally, in the context of Public Sector Innovation, several policy documents may consider APIs for their technical implementation. For example, the Single Digital Gateway Regulation aims to allow citizens and businesses to seamlessly benefit from fully electronic public services (21 procedures) from any member state of the union by the end of 2023 [55]. The flexibility that the modular nature of APIs provides to public administration can facilitate the achievement of this goal. Similarly, APIs could help to enhance interoperability among public administration, business, and citizens. For example, the definition of solutions and common frameworks under the European Interoperability Framework (EIF) could benefit from incorporating technical, organisational, and legal features of API infrastructure in their processes [56,57].

3.2. API Technical Design and Standards

Our study focused on the description and classification of the collected general-purpose standards and technical specifications based on the specific aspect of an API they address. Rather than focusing on current technological trends, this approach aims to capture relevant aspects of APIs which will remain valid even with the emergence of new APIs, specifications, data formats, protocols, etc. Besides, this kind of classification can help in searching new documents by providing a narrower context to conduct researches in document repositories.
We found that web APIs can be classified into two main types: (i) Remote Procedure Call (RPC) APIs and (ii) APIs that adhere to the REST architectural style, or RESTful APIs. RPC APIs are characterised by a set of procedures or methods that the client application can invoke and are executed by the server to fulfil a task, for example, data exchange or a data validation service call. RESTful APIs are based on the REST architectural style introduced by [58]. The REST architectural style is a hybrid style derived from several of the network-based architectural styles and combined with additional constraints that define a uniform connector interface (client-server, stateless interaction, uniform interface, hypermedia as the engine of application state (HATEOAS), cache, layered system and code on demand).
A total of 86 documents were collected and classified by their type (RPC or REST). Out of the total number of collected documents, 15 were related to RPC APIs and 21 to RESTful APIs. The rest of the documents can be considered neutral concerning the architectural style. This distribution indicates that both RPC and REST are widely adopted and that mainly the selection of which style to use depends on the specific use case to be implemented.
We further classified the API standards and specifications into distinct categories, based on the use these APIs have been created for.This involves defining what functionalities are provided by the API and how, that is, defining the utilised resource representation (e.g., data formats, vocabularies, encoding/serialisation) and communication protocol (i.e., rules, syntax, semantics, synchronisation of communication). The rest of the categories include APIs dealing with security (i.e., aspects related to authentication and authorisation), usability (i.e., aspects related to API documentation and design), testing (i.e., documents and tools used for API testing by application developers), performance (i.e., documents describing either methodologies to assess performances, service-level agreements (SLAs), scalability and reliability) and licensing (i.e., documents dealing with different approaches to licensing, defining the terms of usage, distribution, and modification, and ensuring security measures are agreed upon as well).
Figure 1 depicts the number and the type of technical specifications and standards according to the above-illustrated classification. Almost 25% of documents deals with the functional specification category (resource representation and protocol), indicating how this aspect is central to API standardisation. The smallest number of technical specifications and standards belongs to the license category, probably meaning that at the moment licensing lies mainly at the data level.
One of the main challenges of the study was to select the most currently used standards and specifications to provide API developers with a shortlist of documents they can quickly consult. A rough estimate was done by examining different scientific literature repositories and online documents/fora. A shortlist of documents based on their utilisation, maintenance and stability include:
  • Resource representation: Hypertext Application Language (HAL) [59], JSON:API [60], Schema.org [61], and Structured Interface for Representing Entities (SIREN) [62].
  • Communication protocols: GraphQL [63] and gRPC [64].
  • Security: Open Web Application Security Project (OWASP) [65].
    –
    Authentication: OpenID Connect [66] and Security Assertion Markup Language (SAML) [67].
    –
    Authorisation: Extensible Access Control Markup Language (XACML) [68], and OAuth 2.0 [69].
  • Documentation: AsyncAPI specification [70] and OpenAPI specification (OAS) [71].
  • Design: OData [72].
  • Test (tools): Postman collections [73] and Swagger [74].
  • Performance: Cloud computing [75] and IT, cloud computing and SLA framework [76].
  • Licensing: Creative Commons Licenses [77] and Swedish API licence [78].
The study found many aspects of APIs that have been standardised or for which specifications have been reported and used. However, due to the richness of proposals (published during an extended period) and the relatively heterogeneous set of solutions, it can be challenging to identify a unique solution that covers each aspect without, as in the architectural style, considering the specific use case.

3.3. API Adoption and Implementation in Governments

The analysis of the level of adoption of APIs in European governments distil from (i) a survey on API strategies in public administration, (ii) data from Programmable Web [32] and (iii) data gathered by the team on API government cases [79].
Thirty-five European governments’ representatives replied to the survey (22 at national level, 8 at regional level and 5 at city level). Figure 2 depicts the maturity-level spectra of the sample. Twelve organisations already had an enacted API strategy of which three have even already made amendments to it. Sixteen organisations have ongoing API strategy design processes and five organisations do not have an API strategy or plan to have a specific API strategy in the near future.
Although limited in size, the responses of the survey helped to identify barriers, drivers, risks and challenges that API practitioners encounter when adopting APIs in the public sector. It also supported assessing potential risks and mitigation actions.
  • Drivers. The main drivers appear to be related to organisational policies and external stakeholder demand, including the demand both for specific APIs and for specific applications powered by APIs. It was recognised that new legislation has encouraged the adoption of APIs, with motivations being to make data more universally available. Legal drivers were also predicted as drivers in the API strategies under design. Moreover, there was an interest in regulatory actions for APIs.
  • Enablers. Regarding the organisational perspective, the multi-stakeholder and multilevel cooperation, political support and potential legislation (although these were not necessarily API-specific, the existence of API development communities as a living ecosystem around the APIs and the availability of appropriate qualification profiles, both within and outside organisations, were recognised as key enablers for API strategy design. From the budgetary perspective, the availability of funds (both internal and external) and EU initiatives and funding were also was acknowledged as enablers. From the technical perspective, the most acknowledged enabler was the availability of standards, specifications and guidelines, alongside the consensus on the identification of patterns of when to apply different standards and the availability of API platforms and connection with new technologies (AI and the IoT).
  • Barriers. Organisational/cultural barriers were identified as the most relevant barriers impeding API adoption. In particular, APIs are often perceived as primarily beneficial for external parties. A change in the political context, strategies and goals can also affect API investments in the medium and long term. Resistance to change should also not be overlooked, especially when APIs are presented as alternatives to the long-invested legacy systems that some organisations have in place and understand well. The operational/technical barriers identified were mostly related to the time and costs associated with re-engineering existing systems to APIs and to the lack of harmonisation of agile solutions, even within organisations. Two political barriers were also identified, specifically decision makers’ lack of understanding of APIs’ potential and the lack of direct visible benefits for senior managers. Regarding legal barriers, when implementing APIs, some specific regulations must be taken into consideration. The Regulation (EU) 2016/679 on General Data Protection (GDPR), in particular, was acknowledged as a barrier that could slow down the API adoption on the basis of its implications on any project involved in sharing data. Social barriers are not normally anticipated for the adoption of API solutions under design. Economic barriers to API adoption in government environments were also identified. Specifically mentioned were the fact that APIs are more expensive than plain/bulk data exchange, along with the long-term commitments that API systems require. The difficulty in providing a good-quality governmental API ecosystem was also described as a barrier in economic terms, together with the competition for resources with the adoption of API solutions.
  • Risks and mitigating measures. A number of risks were identified, which can be grouped into technical, organisational, legal and economic risks.
    –
    Within the technical risks, cybersecurity is considered as the major threat in both actual and potential API strategies. Therefore, APIs must be appropriately secure in terms of protection against cyberattacks. Technical sustainability is also a concern for API adoption, including the risk of producing APIs that either will not scale or prove to be unstable in the future, because of technical changes/updates. A possible mitigation measure is to identify, analyse and propose a set of existing standards that can be used to implement government APIs, as illustrated in Section 3.2. A possible risk was indicated in the difficulty in maintaining API specifications aligned with the current version of APIs. To mitigate this risk and facilitate the alignment between the documentation and the publication of APIs, tools that help in semi-automatic documentation generation and alignment could be used.
    –
    Related to organisational risks, organisational change and a lack of political support seemed to be particularly relevant. As a mitigation measure, the creation of a central ‘innovation agency’ that can inform IT departments was seen as being beneficial, particularly in terms of communication and coordination. Competing initiatives (i.e., the adoption of APIs without common guidelines and governance) have also been identified as both actual and potential risks. To mitigate these risks, iterative and continuous development approaches should be considered, and should, potentially, also be considered for the strategy itself.
    –
    Legal risks include a breach of the data privacy of people and organisations. Protection from possible access and misuse of these data must be considered as a primary goal for an organisation adopting APIs.
    –
    Economic risks include many aspects, such as the risk of low usage of APIs, the loss of visibility of government activities on the web and business models becoming endangered by specific agencies or sectors of a public administration delivering their data via traditional channels. Some mitigation measures have been introduced and, as observed in our research, regarding business models in the public sector, generating income from the provision of data that are publicly owned and are being used for the public good has not led to the charging of users who wish to consume or query this type of data.
In parallel to our research of API strategies, and to complement it, we also have investigated the availability of concrete implementation of the strategies, i.e., on web API cases. We started doing a preliminary analysis just considering the API registered in the ProgrammableWeb API directory.
Figure 3 shows the list of APIs that have been registered in the period 2005–2019 (first quarter). In August 2019, on a total of 21,202 records, around 2% (417 cases) had been categorised as ‘government’ with the primary keyword (see Table 2). We could notice how the number of these cases has grown steadily since 2012. However, we also observed that adoption of APIs in government in the European Union is still scarce and uneven. To be noted that the small number of European cases might have been affected by the fact that, even if the registry is a well known international initiative, the ProgrammableWeb registry has born in the US is quite active in that country and that is currently maintained by a company based in the US.
Starting from the analysis of the ProgrammableWeb cases and the other sources mentioned in Section 2, we have identified 219 cases distributed among European Union Member States, the United Kingdom and the European Free Trade Association (EFTA) countries. Table 3 shows the total number of cases in these countries and their distribution by international, national and local (i.e., regional and city) administrative levels.
We have also identified a number of APIs that are not specifically linked to any country but have been published by the European Union (42 cases) or by international communities active within the European Union or EFTA countries’ boundaries (15 cases).
Figure 4 shows the number of APIs classified for each type of API. The majority of the cases are related to ‘specific’ APIs (i.e., those that have been created for a specific purpose in government). In this group, we also included APIs that are intended in the ‘traditional’ way (i.e., an endpoint or a group of endpoints that let developers find a web URL that they can use to build their applications). APIs for ‘data catalogues’ are also represented by a high percentage number of cases. Some of these catalogues, such as the European Union Open Data Portal and the INSPIRE Geoportal, let a developer search among thousands of datasets via APIs.
Figure 5 shows our classification by theme. API registries and APIs that grant access to data catalogues have been classified as ‘various’, as they give access to a number of heterogeneous APIs related to many domains. Geospatial APIs are normally made available by the geospatial catalogues (almost all of these APIs have been gathered and collected thanks to INSPIRE Directive and the EU wide contribution to the INSPIRE Geoportal), while government APIs are normally APIs that have been published by governments to give access to a service such as budgeting or administrative registries. A number of APIs have been published for companies’ registries under the theme ‘business’ and on the transparency of government politics (e.g., on the activities by politicians) under the theme ‘politics’.
From the analysis of the API proposed methods and cases, besides the investigation into enablers, drivers, challenges and risks of the Section 3.3, we observed that the adoption of APIs in government is in quite an early stage, with the oldest API strategy having been implemented only in 2014, and several are planned to be deployed within 2018 (i.e., at the time the survey was proposed and the case studies were analysed). API strategies’ stakeholder involvement and stakeholder dynamics vary greatly depending on the nature of the organisations (e.g., the sector, if it is a smart city and the difference between national and international bodies). Often, current API strategies are embedded within or linked to other ICT initiatives.
In addition, looking at the cases studied, web APIs strongly support the digital transformation of government. From the multiple-case study, we also observed that when API strategies and solutions are implemented their uptake is rapid and extensive. This demonstrates, at least in the cases that we have analysed and that had a well-defined goal, that, when implemented, APIs are used by a huge number of applications. In addition, in the cases analysed, APIs enable a digital connection with a high number of third-party organisations.

3.4. API Best-Practices for the Public Sector

The proposed method literature review found that:
  • An uneven distribution of proposed method documents, with governments in higher-income countries more likely to be included in the literature review documents.
  • Of the documents selected, 67 covered all of the European Union areas, and 91 were classified as ‘international’, coming from either private industry or international organisations such as the OECD or the UN. The remainder were from the European Member States and other countries(To clarify that many documents could not have been retrieved because of the language barrier.).
  • API strategy and design within the government is a new approach, with many practitioners still working on implementations. These actions are not yet giving rise to the publication of peer-reviewed policy and implementation experiments. Government API practitioners tend to share their experiences and their reflections on implementation via blog posts and presentations.
  • Based on the ‘Type’ classification made during the literature review process (that is proposed method, guideline or recommendation), the majority (45%) of documents were categorised as proposed methods, that is, there was significant strength of evidence to suggest that other governments could consider how to apply the implementation practices to their own context. 30% were grouped as guidelines, that is that they showed promising practices, often from pilot or department-specific situations in which they had been implemented, and 25% were classified as recommendations, that is, they were theoretical approaches that describe how they should work based on other implementation evidence, or were from pilots that had been attempted in fairly narrow implementation environments.
In Figure 6, the main topic covered by each document is categorised, with these then grouped into API strategy (dark blue), API tactical (mid blue) and API operational (light blue). In the literature, the strongest consistency and evidence-based agreement were on operational aspects of API implementation, especially operational issues that were technical, such as in designing APIs.
Following the completion of the analysis of all 343 documents, we selected and created a shortlist of documents that could be used by governments as reference literature. The list includes the following documents:
  • International and strategic-oriented documents:
    –
    The UN Environment Programme (UNEP) science business policy forum discussion paper: The case for a digital ecosystem for the environment [80].
    –
    The new European Interoperability Framework (EIF) [57].
    –
    The European Commission’s European Union Location Framework (EULF) blueprint [81].
    –
    McKinsey and Company documents on its works with a wide range of large enterprises on reorienting their operations towards an API-first approach [82,83].
  • Guidelines at government level (in alphabetical order):
    –
    Australia (Victoria): API guidelines and related information management framework [84,85].
    –
    Canada: API guidelines (Government of Canada, 2019a);
    –
    Finland: 6Aika proposed methods library [86].
    –
    France: the FranceConnect system (presentation) [87].
    –
    Italy: the Italian 2019–2021 3-year plan for IT in the public administration [88].
    –
    New Zealand: API guidelines [89].
    –
    Singapore: Finance-as-a-Service: API playbook [90].
    –
    The Netherlands: API strategy for the Netherlands government [91].
    –
    The United Kingdom: helping government use APIs better and Making Government as a Platform Real [92].

4. Discussion and Conclusions

The need to propose an exhaustive landscape analysis derives from the requirements of the APIs4DGov study undertaken by the European Commission Joint Research Centre (JRC) in partnership with the Directorate-General for Communications Networks, Content and Technology of the European Commission (DG CONNECT). One of the objectives of the project was the review the current landscape of government APIs in the EU Members States and, in the case of the proposed methods and standards documents, also outside the EU. By considering the API adoption in the private sector, which started more than 20 years ago, we soon realised that a proper investigation on the API landscape in the public sector (the ‘what’) was absolutely needed to support the motivations (the ‘why’) and, mostly, the way to implement APIs in government (the ‘how’). This paper presents the results of our investigation, considering that no previous analysis was done at the European level on this topic. Specifically, we discuss the landscape analysis of API adoption along three main axes: technical, organisational, and policy context.
On the technical front, we first explored the status quo of API adoption in the public sector. The conclusions are (i) that APIs have long been part of the digital infrastructures in public administration at all administrative levels (Pan-European, National, Regional and Local levels) but mainly used within ad-hoc solutions, (ii) that API adoption is uneven and often not optimally coordinated, thus missing the ‘digital ecosystem’ vision and (iii) that APIs are a foundational component in the raising concept of ‘Connected Government’.
Then, we gathered common definitions, standards, technical specifications in use, and proposed methods. We observed that the use of available standards and technical specifications in API infrastructures make organisations achieve greater digital flexibility, integrability and exploitability of their digital assets. The identified material on standards could be used to support the technical implementation of APIs and also contribute to update European Commission reference documents on interoperability, online guidance, training or other reference information for APIs.
Additionally, we performed an extensive literature review of API proposed methods, recommendations and guidelines. The results of our investigations include a summary of the common approaches identified from multiple governments and private industry good practice documents. Practices, guidelines and recommendations were grouped into strategical, tactical and operational target levels. The documents were further tagged with relevant topic headings such as ‘governance’, ‘metrics’, ‘security’, ‘API design’ and ‘documentation’. Topic headings were later grouped into thematic areas such as ‘governance’, ‘policy alignment’, ‘technical implementation’ and ‘team composition’. These methodology represented a solid base to build a cohesive framework for API adoption in governments [6] and its categorisation could represent useful search facets to browse the list of documents [17] by possible interested users.
On the organisational front, we observed a great variation of API strategies in the public sector both in scope and level of application. For instance, different levels of governments typically behave differently: national-level actors focus on providing access to data, whereas local and regional organisations are service-delivery oriented. Another observation was that most of the API strategies analysed had an operational/implementation scope. A few of them included also a tactical perspective including the setting up of common infrastructure and API implementation guidelines. However, most of them had a limited view of the strategic elements that would place APIs in digital government thinking. In other words, current API adoption initiatives focus on making individual organisation’s resources available, but little thought is given to the creation of an ecosystem around these assets, whereby certain processes or applications rely on the reuse of APIs in multi-stakeholder contexts.
On the policy front, from the analysis of the policy documents, we conclude that APIs already feature in recent policy initiatives in Europe. In particular, concerning the unlocking of the value of data envisioned under the Data, Industrial and Artificial Intelligence strategies. The analysed policy documents explicitly or implicitly count on APIs to streamline the use and enable the re-use and monitoring of data sharing. Following the trends we have observed, we expect that policy provisions, such as the Digital Europe Programme [93], will sustain the implementation of APIs in the public sector.
As a final conclusion, we think the proposed work and results have contributed the state-of-the-art research in regards to the API landscape in governments. All the collected material offered a solid reference base to analyse motivations and impact of APIs in governments [4]. The main result of this investigation provides solid background knowledge to support further research in the field and so to enhance the digital transformation of governments. All the datasets, including the list of cases, the list of documents about proposed methods and the questionnaires are available as open data at the JRC Data Catalogue https://data.jrc.ec.europa.eu/collection/id-0097 (accessed on 6 June 2021). Moreover, all the material of our past, current and next studies related to the API contribution to the digital transformation of the public sector are available at the European Commission JoinUp platform https://joinup.ec.europa.eu/collection/api4dt (accessed on 6 June 2021).

Author Contributions

Conceptualization, L.V. and M.P.; methodology, L.V., M.P., M.B. and M.S.; investigation, L.V., M.P., M.B. and M.S.; resources, L.V., M.P., M.B. and M.S.; data curation, L.V., M.P., M.B. and M.S. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

All the data supporting this study have been published as open data at the Joint Research Centre Data Catalogue https://data.jrc.ec.europa.eu/collection/id-0097 (accessed on 6 June 2021).

Acknowledgments

The authors would like to show their gratitude to all the colleagues, experts and private and public organisations for their comments and support and in particular to: all the current and former colleagues of the Digital Economy Unit of the Joint Research Centre (JRC); all the colleagues of DIGIT and CONNECT DGs of the European Commission and in particular to Dietmar Gattwinkel for his support during all the phases of the APIs4dgov project; David Berlind of the ProgrammableWeb company that agreed on providing us the list of cases on which some of the results of this work have been based on; Roberto Polli of the Italian Digital Transformation Team for his support in clarifying API technical solutions and standards; Mehdi Medjaoui and the entire team of the APIdays series of conferences for letting us collaborating on the private/public sectors knowledge exchange; all the representatives of a huge number of governments for their active participation in all our activities; and all the API experts that actively participated to our discussions and improved our knowledge on the API landscape for governments.

Conflicts of Interest

The authors declare no conflict of interest.

Abbreviations

The following abbreviations are used in this manuscript:
APIApplication Programming Interface
APIs4DGovAPI for Digital Government
AIArtificial Intelligence
JRCJoint Research Centre
HVDsHigh Value Datasets
SMESmall and Medium-sized Enterprise
GDPRGeneral Data Protection Regulation
PSD2Payment Services Regulation 2
EIFEuropean Interoperability Framework

References

  1. Cotton, I.; Greatorex, F. Data Structures and Techniques for Remote Computer Graphics. International Workshop on Managing Requirements Knowledge. 1968. Available online: https://www.computer.org/csdl/proceedings/afips/1968/5072/00/50720533.pdf (accessed on 7 June 2021).
  2. Shnier, M. Dictionary of PC Hardware and Data Communications Terms; O’Reilly Media, Inc.: Sebastopol, CA, USA, 1996. [Google Scholar]
  3. European Union. Directive (EU) 2019/1024 on Open Data and the Reuse of Public Sector Information. 2019. Available online: http://data.europa.eu/eli/dir/2019/1024/oj/eng (accessed on 18 July 2019).
  4. Vaccari, L.; Posada, M.; Boyd, M.; Gattwinkel, D.; Mavridis, D.; Smith, R.S.; Santoro, M.; Nativi, S.; Medjaoui, M.; Reusa, I.; et al. Application Programming Interfaces in Governments: Why, What and How. 2020. Available online: http://dx.doi.org/10.2760/58129 (accessed on 1 September 2020).
  5. Santoro, M.; Vaccari, L.; Mavridis, D.; Smith, R.; Posada, M.; Gattwinkel, D. Web Application Programming Interfaces (APIs): General-Purpose Standards, Terms and European Commission Initiatives. 2019. Available online: https://ec.europa.eu/jrc/en/publication/web-application-programming-interfaces-apis-general-purpose-standards-terms-and-european-commission (accessed on 20 November 2019).
  6. Boyd, M.; Vaccari, L.; Posada, M.; Gattwinkel, D. An Application Programming Interface (API) Framework for Digital Government. 2020. Available online: https://publications.jrc.ec.europa.eu/repository/bitstream/JRC120715/final_version_pdf_version.pdf (accessed on 10 August 2020).
  7. European Commission. ICT Impact Assessment Guidelines. 2017. Available online: https://ec.europa.eu/isa2/sites/isa/files/ict_impact_assessment_guidelines.pdf (accessed on 18 April 2019).
  8. Williams, M. Digital Government Benchmark—API Study; Technical Report; Joint Research Centre (JRC), European Commission: Ispra, Italy, 2018. [Google Scholar]
  9. European Commission. Digital Champions. 2014. Available online: https://ec.europa.eu/digital-single-market/en/digital-champions (accessed on 29 January 2020).
  10. European Commission. Interoperability of European Public Services (E03714) Expert Group. 2020. Available online: https://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetail&groupID=3714&news=1 (accessed on 15 February 2021).
  11. European Commission. eGovernment Action Plan Steering Board. 2016. Available online: https://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetail&groupID=3438&NewSearch=1&NewSearch=1 (accessed on 29 January 2020).
  12. Open & Agile Smart Cities. International Coalition of Cities Builds Global Interoperable Smart Cities Market. 2019. Available online: https://oascities.org/international-coalition-of-cities-builds-global-interoperable-smart-cities-market/ (accessed on 12 February 2019).
  13. Apidays Global. APIdays London-October 27 & 28. 2020. Available online: https://www.apidays.co/london/ (accessed on 12 October 2020).
  14. European Commission. Joinup. 2019. Available online: https://joinup.ec.europa.eu/ (accessed on 12 April 2019).
  15. European Commission. APIS4DGov API Strategy Case Studies Interviews: Questionnaire. 2019. Available online: http://data.europa.eu/89h/6715ba30-70be-4e9b-96e0-93eed8b6262d (accessed on 7 June 2021).
  16. Boyd, M.; Vaccari, L.; Posada, M.; Gattwinkel, D. API Framework Self-Assessment Maturity Tool for Governments. 2020. Available online: https://ec.europa.eu/eusurvey/runner/APIFrameworkTool (accessed on 4 July 2020).
  17. Boyd, M.; Vaccari, L. API Best Practice Documents Relevant to Governments: Comprehensive Literature Review. 2020. Available online: http://data.europa.eu/89h/7340ab8a-ef73-459b-a2d9-b64e1a5bb680 (accessed on 13 August 2020).
  18. Boyd, M.; Vaccari, L. API Adoption Self-Assessment: Questionnaire. 2020. Available online: http://data.europa.eu/89h/b387b652-70c1-4b69-b730-cc1391781390 (accessed on 16 February 2021).
  19. European Commission. APIs4DGov List of API Cases studied. 2019. Available online: https://data.jrc.ec.europa.eu/dataset/8fad917f-c6a6-4d17-9123-bcc6749bd902 (accessed on 7 June 2021).
  20. European Commission. APIs4DGov Study Workshop: Assessing Government API Strategies across the EU. 2018. Available online: https://ec.europa.eu/jrc/en/event/workshop/assessing-government-api-strategies-across-eu (accessed on 13 March 2019).
  21. European Commission. INSPIRE Hackathon 2018. Available online: https://www.plan4all.eu/inspire-hackathon-2018/ (accessed on 8 April 2019).
  22. European Commission. Event IV (11/12/2019): APIs for Governments: Public Sector Track and Workshop. 2019. Available online: https://joinup.ec.europa.eu/collection/api4dt/event/event-iv-11122019-apis-governments-public-sector-track-and-workshop (accessed on 16 February 2021).
  23. European Commission. Event II (4-5/06/2019): APIs for Governments: Private and Public Sector API Experiences. 2019. Available online: https://joinup.ec.europa.eu/collection/api4dt/event/event-ii-4-5062019-apis-governments-private-and-public-sector-api-experiences (accessed on 16 February 2021).
  24. European Commission. Event III (12-13/09/2019): APIs for Governments: API Public Sector Track and Workshop. 2019. Available online: https://joinup.ec.europa.eu/collection/api4dt/event/event-iii-12-13092019-apis-governments-api-public-sector-track-and-workshop (accessed on 16 February 2021).
  25. European Commission. Workshop II (27/10/2020): API Technical Essentials: Public Administration & Private Sector APIs co-design. 2020. Available online: https://joinup.ec.europa.eu/collection/api4dt/event/workshop-ii-27102020-api-technical-essentials-public-administration-private-sector-apis-co-design (accessed on 26 October 2020).
  26. European Commission. Workshop I (25/09/2020): API Technical Essentials: Public Administration & Private Sector APIs co-design. 2020. Available online: https://joinup.ec.europa.eu/collection/api4dt/event/workshop-i-25092020-api-technical-essentials-public-administration-private-sector-apis-co-design (accessed on 26 October 2020).
  27. OGC. Glossary of Terms—S. 2019. Available online: https://www.opengeospatial.org/ogc/glossary/s (accessed on 8 April 2019).
  28. European Commission. APIs4DGov API Strategy Survey. 2018. Available online: https://ec.europa.eu/eusurvey/runner/APIs4DGov-Strategy (accessed on 8 April 2019).
  29. Wittern, E.; Muthusamy, V.; Laredo, J.A.; Vukovic, M.; Slominski, A.; Rajagopalan, S.; Jamjoom, H.; Natarajan, A. API Harmony: Graph-Based Search and Selection of APIs in the Cloud. IBM J. Res. Dev. 2016, 60, 1–11. [Google Scholar] [CrossRef]
  30. Lane, K. My Primary API Search Engines. 2019. Available online: https://apievangelist.com/2019/07/12/my-primary-api-search-engines/ (accessed on 17 January 2020).
  31. APIs.io. The API Search Engine. 2020. Available online: http://apis.io/ (accessed on 17 January 2020).
  32. ProgrammableWeb.com. ProgrammableWeb API Directory. 2020. Available online: https://www.programmableweb.com/category/all/apis (accessed on 17 January 2020).
  33. APIs.guru. API Tooling Development: GraphQL, OpenAPI. 2020. Available online: https://APIs.guru/ (accessed on 17 January 2020).
  34. European Commission. Towards Faster Implementation and Uptake of Open Government: Final Report. 2016. Available online: https://op.europa.eu/en/publication-detail/-/publication/1071fdcc-aa45-11e6-aab7-01aa75ed71a1/language-en/format-PDF%7D (accessed on 7 September 2017).
  35. European Commission. Open eGovernment Practices in All EU Member States Make Public Services More Collaborative, Efficient and Inclusive. 2016. Available online: https://ec.europa.eu/digital-single-market/en/news/open-egovernment-practices-all-eu-member-states-make-public-services-more-collaborative (accessed on 7 February 2019).
  36. European Commission. European Blockchain Services Infrastructure (EBSI). 2020. Available online: https://ec.europa.eu/cefdigital/wiki/cefdigital/wiki/display/CEFDIGITAL/EBSI (accessed on 15 January 2020).
  37. European Commission. European Data Portal—Use Cases. 2019. Available online: https://www.europeandataportal.eu/en/using-data/use-cases (accessed on 19 March 2019).
  38. European Commission. INSPIRE Geoportal. 2020. Available online: //inspire-geoportal.ec.europa.eu/ (accessed on 17 January 2020).
  39. IETF. Keywords for Use in RFCs to Indicate Requirement Levels. 1997. Available online: https://www.ietf.org/rfc/rfc2119.txt (accessed on 6 February 2020).
  40. European Commission. Shaping Europe’s Digital Future: Commission Presents Strategies for Data and Artificial Intelligence. 2020. Available online: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_273 (accessed on 20 February 2020).
  41. European Commission. A European Strategy for Data COM/2020/66. 2020. Available online: https://ec.europa.eu/info/sites/info/files/communication-european-strategy-data-19feb2020_en.pdf (accessed on 26 February 2020).
  42. European Commission. A new Industrial Strategy for Europe COM/2020/102. 2020. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020DC0102 (accessed on 26 March 2020).
  43. European Commission. White Paper on Artificial Intelligence: A European Approach to Excellence and Trust COM/2020/65 Final. 2020. Available online: https://ec.europa.eu/info/publications/white-paper-artificial-intelligence-european-approach-excellence-and-trust_en (accessed on 23 February 2021).
  44. European Union. Directive (EU) 2007/2/EC Establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). 2007. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02007L0002-20190626 (accessed on 12 October 2019).
  45. European Union. Regulation (EU) 2016/679 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data. 2016. Available online: https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed on 24 October 2019).
  46. European Union. Directive (EU) 2015/2366 on Payment Services in the Internal Market. 2015. Available online: https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en (accessed on 19 March 2019).
  47. Lutz, M.; Jari, R.; Kotsev, A. Discussion Paper on INSPIRE IR’s for Network Services Mapping with WFS 3.0; Technical Report; Joint Research Centre (JRC), European Commission: Ispra, Italy, 2019. [Google Scholar]
  48. Kotsev, A.; Schleidt, K.; Liang, S.; Van der Schaaf, H.; Khalafbeigi, T.; Grellet, S.; Lutz, M.; Jirka, S.; Beaufils, M. Extending INSPIRE to the internet of things through SensorThings API. Geosciences 2018, 8, 221. [Google Scholar] [CrossRef] [Green Version]
  49. European Commission. Good Practice Library-INSPIRE. 2021. Available online: https://inspire.ec.europa.eu/portfolio/good-practice-library (accessed on 24 March 2021).
  50. Zachariadis, M.; Ozcan, P. The API Economy and Digital Transformation in Financial Services: The Case of Open Banking. Available online: https://papers.ssrn.com/abstract=2975199 (accessed on 17 February 2021).
  51. European Commission. Proposal for a Regulation on European Data Governance (Data Governance Act). 2020. Available online: https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-european-data-governance-data-governance-act (accessed on 21 December 2020).
  52. European Commission. Digital Markets Act: Ensuring Fair and Open Digital Markets. 2021. Available online: https://ec.europa.eu/commission/presscorner/detail/en/QANDA_20_2349 (accessed on 7 January 2021).
  53. European Commission. The Digital Services Act: Ensuring a Safe and Accountable Online Environment. 2020. Available online: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-services-act-ensuring-safe-and-accountable-online-environment_en (accessed on 5 March 2021).
  54. European Commission. SME Strategy for a Sustainable and Digital Europe, COM/2020/103. 2020. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020DC0103 (accessed on 2 March 2021).
  55. European Union. Regulation (EU) 2018/1724 Establishing a Single Digital Gateway to Provide Access to Information, to Procedures and to Assistance and Problem-Solving Services. 2018. Available online: http://data.europa.eu/eli/reg/2018/1724/oj/eng (accessed on 7 August 2019).
  56. European Union. Decision (EU) 2015/2240. Establishing a Programme on Interoperability Solutions and Common Frameworks for European Public Administrations, Businesses and Citizens (ISA2 Programme) As a Means for Modernising the Public Sector. 2015. Available online: http://data.europa.eu/eli/dec/2015/2240/oj/eng (accessed on 12 August 2019).
  57. European Commission. New European Interoperabilty Framework—Brochure. 2017. Available online: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf (accessed on 15 April 2019).
  58. Fielding, R.T. Architectural Styles and the Design of Network-Based Software Architectures. Ph.D. Thesis, University of California, Irvine, CA, USA, 2000. [Google Scholar]
  59. Kelly, M. The Hypertext Application Language (HAL). 2011. Available online: http://stateless.co/hal_specification.html (accessed on 15 May 2020).
  60. Katz, Y.; Gebhardt, D.; Sullice, G. JSON:API —A Specification for Building APIs in JSON. 2015. Available online: https://jsonapi.org/ (accessed on 15 May 2020).
  61. Community, S. Schema.org. 2020. Available online: https://schema.org/ (accessed on 26 April 2020).
  62. Swiber, K. Structured Interface for Representing Entities (Siren). 2012. Available online: https://github.com/kevinswiber/siren (accessed on 15 May 2020).
  63. Facebook. GraphQL. 2020. Available online: http://spec.graphql.org/ (accessed on 4 April 2019).
  64. Google. gRPC. 2020. Available online: https://grpc.io/docs/ (accessed on 13 June 2018).
  65. 42Crunch. OWASP API Security Top 10 Protection. 2020. Available online: https://42crunch.com/owasp-api-security-top-10/ (accessed on 2 March 2021).
  66. Foundation, O. OpenID Connect. 2020. Available online: https://openid.net/connect/ (accessed on 15 May 2020).
  67. OASIS. Security Assertion Markup Language (SAML). 2019. Available online: https://wiki.oasis-open.org/security/FrontPage (accessed on 15 May 2020).
  68. OASIS. eXtensible Access Control Markup Language (XACML). 2017. Available online: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml (accessed on 15 May 2020).
  69. IETF. OAuth 2.0. 2020. Available online: https://oauth.net/2/ (accessed on 15 May 2020).
  70. initiative, A. AsyncAPI, Coming from OpenAPI. 2020. Available online: https://www.asyncapi.com/docs/getting-started/coming-from-openapi/ (accessed on 26 April 2020).
  71. OAI. OpenAPI Specification (OAS). 2020. Available online: https://www.openapis.org/ (accessed on 15 May 2020).
  72. OData. OData—The Best Way to REST. 2019. Available online: https://www.odata.org/ (accessed on 4 April 2019).
  73. Postman. Postman Collection. 2020. Available online: https://www.postman.com/collection/ (accessed on 15 May 2020).
  74. Swagger.io. About Swagger. 2019. Available online: https://swagger.io/about/ (accessed on 1 September 2018).
  75. ISO.; IEC. ISO/IEC 17789:2014, Information Technology —Cloud Computing —Reference Architecture. 2014. Available online: http://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/06/05/60545.html (accessed on 12 November 2019).
  76. ISO; IEC. ISO/IEC 19086-1:2016, Information Technology—Cloud Computing—Service Level Agreement (SLA) Framework—Part 1: Overview and Concepts. 2016. Available online: https://standards.iso.org/ittf/PubliclyAvailableStandards/c067545_ISO_IEC_19086-1_2016.zip (accessed on 12 November 2019).
  77. Creative Commons. Choose a License. 2019. Available online: https://creativecommons.org/choose/ (accessed on 23 July 2019).
  78. Swedish Governmental Agency for Innovation Systems. Swedish API License. 2020. Available online: https://apilicens.se/en/ (accessed on 25 February 2020).
  79. Vaccari, L. Publicly Available API Government Cases. 2020. Available online: http://data.europa.eu/89h/45ca8d82-ac31-4360-b3a1-ba43b0b07377 (accessed on 25 January 2020).
  80. Jensen, D.; Campbell, J. The Case for a Digital Ecosystem for the Environment. Discussion Paper: Bringing Together Data, Algorithms and Insights for Sustainable Development. 2018. Available online: https://un-spbf.org/wp-content/uploads/2019/03/Digital-Ecosystem-final.pdf (accessed on 29 July 2019).
  81. European Commission. European Union Location Framework (EULF) Blueprint. 2019. Available online: https://joinup.ec.europa.eu/collection/european-union-location-framework-eulf/eulf-blueprint (accessed on 23 February 2018).
  82. McKinsey. Cutting through the Noise: How Banks Can Unlock the Potential of APIs. 2019. Available online: https://www.mckinsey.com/industries/financial-services/our-insights/banking-matters/cutting-through-the-noise-how-banks-can-unlock-the-potential-of-apis (accessed on 7 February 2020).
  83. Iyengar, K.; Lau, L.; Ramadath, S.; Sohoni, V. The Seven Make-or-Break API Challenges CIOs Need to Address. 2018. Available online: https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the-seven-make-or-break-api-challenges-cios-need-to-address (accessed on 7 February 2020).
  84. Victorian Government. Understand the API Design Principles—Digital Guide. 2019. Available online: https://www.vic.gov.au/understand-our-api-design-principles (accessed on 19 February 2019).
  85. Victorian Government. Policies and Standards for Government IT. 2019. Available online: http://www.vic.gov.au/policies-standards-for-government-IT (accessed on 7 February 2020).
  86. 6Aika. API Toolkit. 2017. Available online: https://6aika.fi/wp-content/uploads/2017/11/20171102_APItoolkit_WEB.pdf (accessed on 13 August 2020).
  87. Amarelis, P. French API Strategy. 2018. Available online: https://ec.europa.eu/jrc/sites/jrcsh/files/18_04_patrick-amarelis_france.pdf (accessed on 4 May 2020).
  88. AGID. Three Year Plan for the ICT in the Public Administration (2019–2021). 2018. Available online: https://docs.italia.it/italia/piano-triennale-ict/pianotriennale-ict-doc/it/2019-2021/index.html (accessed on 7 February 2020).
  89. New Zealand Government. API Standard and Guidelines Part B—Technical. 2016. Available online: https://snapshot.ict.govt.nz/guidance-and-resources/standards-compliance/api-standard-and-guidelines/api-standard-and-guidelines-part-b-technical/ (accessed on 1 February 2019).
  90. ABS-MAS. Finance-as-a-Service. API Playbook. 2016. Available online: https://abs.org.sg/docs/library/abs-api-playbook.pdf (accessed on 7 February 2020).
  91. Geonovum. API Strategie Voor de Nederlandse Overheid. 2019. Available online: https://docs.geostandaarden.nl/api/vv-hr-API-Strategie-20190715/ (accessed on 7 February 2020).
  92. Loosemore, T. Making Government as a Platform Real. 2018. Available online: https://public.digital/2018/09/25/making-government-as-a-platform-real/ (accessed on 7 February 2020).
  93. European Commission. Europe Investing in Digital: The Digital Europe Programme. 2019. Available online: https://ec.europa.eu/digital-single-market/en/europe-investing-digital-digital-europe-programme (accessed on 1 March 2021).

Short Biography of Authors

Data 06 00059 i001Lorenzino Vaccari holds a PhD in Computer Science, obtained in 2009 from the University of Trento, Italy. Lorenzino has more than 30 years of experience and research in the information technology field and led the team working on the application programming interfaces for digital government (APIs4DGov) study. He is a senior expert in digital technologies supporting the evolution of the modern society. His specialities include artificial intelligence, the internet of things, digital government, blockchain, open data and spatial data infrastructures.
Data 06 00059 i002Monica Posada is a PhD candidate at the Wien University of Business and Economics (WU), Austria. She leads a research team at the Digital Economy Unit of the JRC in Ispra, Italy. She is co-author and editor of science for policy and technical reports about the status of the digitisation of public administration. Her work focuses on analysing the techno-socioeconomic impacts of the pervasive uptake of information technologies in the digital era. Her professional interests span various aspects of data science, explicitly applying advanced data analysis and visualisation techniques to design decision support systems.
Data 06 00059 i003Mark Boyd is a writer and policy analyst who focuses on supporting open ecosystems in which everyone can participate and co-create their own value. He was the lead author of the API Framework for Digital Government, written for the European Commission’s Joint Research Centre, and has been working on API strategies and resources for government and businesses for the past 10 years. Prior to that, he worked in public health and urban planning where he designed data models and built dashboards for city governments to address key public health and social well-being needs. He has worked in policy development to reduce inequalities and started his professional career contributing to initiatives that responded to the HIV/AIDS crisis in Australia in the early 90s.
Data 06 00059 i004Mattia Santoro is a researcher at the Institute of Atmospheric Pollution Research of National Research Council of Italy (CNR-IIA). He has a PhD in Methods and Technologies for Environmental Monitoring at the University of Basilicata, Italy (2012). He obtained a master degree in computer science at the University of Florence, Italy (2008). His main research interests cover the design and development of architectures in support of multidisciplinary applications, with particular focus on semantics and model interoperability. He is responsible of the GEO Discovery and Access Broker (DAB) operational environment and coordinates the development of the Virtual Earth Laboratory (VLab) framework.
Data 06 00059 g001 550
Figure 1. Number of technical specifications and standards per category (source: authors’ elaboration based on [4]).
Figure 1. Number of technical specifications and standards per category (source: authors’ elaboration based on [4]).
Data 06 00059 g001
Data 06 00059 g002 550
Figure 2. API strategies maturity level (source: authors’ elaboration).
Figure 2. API strategies maturity level (source: authors’ elaboration).
Data 06 00059 g002
Data 06 00059 g003 550
Figure 3. Adoption of Web APIs. Left panel: cumulative count of the number of web API. Right Panel: cumulative count of the number of the most popular APIs by category (source: authors’ elaboration based on ProgrammableWeb.com data of June 2019 [4]).
Figure 3. Adoption of Web APIs. Left panel: cumulative count of the number of web API. Right Panel: cumulative count of the number of the most popular APIs by category (source: authors’ elaboration based on ProgrammableWeb.com data of June 2019 [4]).
Data 06 00059 g003
Data 06 00059 g004 550
Figure 4. Types of APIs in analysed API cases (N = 219) (source: authors’ elaboration based on [79]).
Figure 4. Types of APIs in analysed API cases (N = 219) (source: authors’ elaboration based on [79]).
Data 06 00059 g004
Data 06 00059 g005 550
Figure 5. APIs classified by theme (N = 219) (source: authors’ elaboration based on [79]).
Figure 5. APIs classified by theme (N = 219) (source: authors’ elaboration based on [79]).
Data 06 00059 g005
Data 06 00059 g006 550
Figure 6. APIs literature by topic and target level (N = 343) (Source: Authors’ elaboration, based on [79]).
Figure 6. APIs literature by topic and target level (N = 343) (Source: Authors’ elaboration, based on [79]).
Data 06 00059 g006
Table
Table 1. Keyword used in the literature review (source: authors’ elaboration).
Table 1. Keyword used in the literature review (source: authors’ elaboration).
CategoriesKeywordsNr. of Keywords
Location-specific termsEU MS names and names of countries where relevant API strategies or preparatory documents were available in English, namely: Argentina, Australia, New Zealand, Singapore, United States, United Kingdom.34
API specific termsGovernment API proposed methods, Government API playbook, Government API recommendations3
Related termsGovernment as a platform, City as a platform2
Table
Table 2. Most common categories of registered web APIs (source: authors’ elaboration, based on ProgrammableWeb.com data of June 2019 [4]).
Table 2. Most common categories of registered web APIs (source: authors’ elaboration, based on ProgrammableWeb.com data of June 2019 [4]).
RankFirst CategoryNumberRankFirst CategoryNumber
1Tools (context independent)99311Telephony398
2Financial94412Security366
3Messaging67113Reference366
4E-commerce65714Search346
5Social61915Email346
6Payments60516Video340
7Enterprise52817Travel321
8Mapping51018Education311
9Government41719Sports303
10Science40120Transportation292
Table
Table 3. API cases by country and administrative level (source: authors’ elaboration based on [79]).
Table 3. API cases by country and administrative level (source: authors’ elaboration based on [79]).
CountryInternationalNationalLocalCountryInternationalNationalLocal
Austria 2 Latvia 2
Belgium 47Liechtenstein 1
Bulgaria 2 Lithuania 1
Croatia 1 Luxembourg12
Cyprus 1 Malta 1
Czechia 7 Netherlands184
Denmark 91Norway 2
Estonia14 Poland 4
Finland 46Portugal 2
France 63Romania 1
Germany 45Slovakia 2
Greece 5 Slovenia 1
Hungary 1 Spain 210
Iceland 1 Sweden 31
Ireland 41Switzerland 1
Italy 56UK1204
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Vaccari, L.; Posada, M.; Boyd, M.; Santoro, M. APIs for EU Governments: A Landscape Analysis on Policy Instruments, Standards, Strategies and Best Practices. Data 2021, 6, 59. https://doi.org/10.3390/data6060059

AMA Style

Vaccari L, Posada M, Boyd M, Santoro M. APIs for EU Governments: A Landscape Analysis on Policy Instruments, Standards, Strategies and Best Practices. Data. 2021; 6(6):59. https://doi.org/10.3390/data6060059

Chicago/Turabian Style

Vaccari, Lorenzino, Monica Posada, Mark Boyd, and Mattia Santoro. 2021. "APIs for EU Governments: A Landscape Analysis on Policy Instruments, Standards, Strategies and Best Practices" Data 6, no. 6: 59. https://doi.org/10.3390/data6060059

APA Style

Vaccari, L., Posada, M., Boyd, M., & Santoro, M. (2021). APIs for EU Governments: A Landscape Analysis on Policy Instruments, Standards, Strategies and Best Practices. Data, 6(6), 59. https://doi.org/10.3390/data6060059

Article Metrics

Back to TopTop