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

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. Keyword used in the literature review (source: authors’ elaboration).

Categories	Keywords	Nr. of Keywords
Location-specific terms	EU 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 terms	Government API proposed methods, Government API playbook, Government API recommendations	3
Related terms	Government as a platform, City as a platform	2

, 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. Most common categories of registered web APIs (source: authors’ elaboration, based on ProgrammableWeb.com data of June 2019 [4]).

Rank	First Category	Number	Rank	First Category	Number
1	Tools (context independent)	993	11	Telephony	398
2	Financial	944	12	Security	366
3	Messaging	671	13	Reference	366
4	E-commerce	657	14	Search	346
5	Social	619	15	Email	346
6	Payments	605	16	Video	340
7	Enterprise	528	17	Travel	321
8	Mapping	510	18	Education	311
9	Government	417	19	Sports	303
10	Science	401	20	Transportation	292

). 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. API cases by country and administrative level (source: authors’ elaboration based on [79]).

Country	International	National	Local	Country	International	National	Local
Austria		2		Latvia		2
Belgium		4	7	Liechtenstein		1
Bulgaria		2		Lithuania		1
Croatia		1		Luxembourg	1	2
Cyprus		1		Malta		1
Czechia		7		Netherlands	1	8	4
Denmark		9	1	Norway		2
Estonia	1	4		Poland		4
Finland		4	6	Portugal		2
France		6	3	Romania		1
Germany		4	5	Slovakia		2
Greece		5		Slovenia		1
Hungary		1		Spain		2	10
Iceland		1		Sweden		3	1
Ireland		4	1	Switzerland		1
Italy		5	6	UK	1	20	4

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).