research paper on application programming interface

State of the Practice in Application Programming Interfaces (APIs): A Case Study

• Conference paper
• First Online: 26 August 2021
• Cite this conference paper

• Mikko Raatikainen   ORCID: orcid.org/0000-0002-2410-0722 14 ,
• Elina Kettunen 14 ,
• Ari Salonen 15 ,
• Marko Komssi 16 ,
• Tommi Mikkonen   ORCID: orcid.org/0000-0002-8540-9918 14 &
• Timo Lehtonen   ORCID: orcid.org/0000-0001-8833-1725 17  

Part of the book series: Lecture Notes in Computer Science ((LNPSE,volume 12857))

Included in the following conference series:

• European Conference on Software Architecture

1713 Accesses

3 Citations

3 Altmetric

Application Programming Interfaces (APIs) have become prevalent in today’s software systems and services. APIs are basically a technical means to realize the co-operation between software systems or services. While there are several guidelines for API development, the actually applied practices and challenges are less clear. To better understand the state of the practice of API development and management in the industry, we conducted a descriptive case study in four Finnish software companies: two consultancy companies developing software for their customers, and two companies developing their software products. As a result, we identified five different usage scenarios for APIs and emphasize that diversity of usage should be taken into account more explicitly especially in research. API development and technical management are well supported by the existing tools and technologies especially available from the cloud technology. This leaves as the main challenge the selection of the right technology from the existing technology stack. Documentation and usability are practical issues to be considered and often less rigorously addressed. However, understanding what kind of API management model to apply for the business context appears as the major challenge. We also suggest considering APIs more clearly a separate concern in the product management with specific practices, such as API roadmapping.

• Software engineering
• Application programming interface
• API management

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

http://www.digia.com .

http://www.solita.fi .

https://www.vertex.fi .

https://www.f-secure.com .

For readability and space reasons, we can only show one quadrant. Full Tech Radar is available at https://techradar.digia.online .

https://semver.org/ .

https://swagger.io/specification/ .

E.g., https://github.com/F-Secure/atlant-api .

Alshuqayran, N., Ali, N., Evans, R.: A systematic mapping study in microservice architecture. In: IEEE International Conference on Service-Oriented Computing and Applications, pp. 44–51 (2016)

Google Scholar  

Artac, M., Borovssak, T., Di Nitto, E., Guerriero, M., Tamburri, D.A.: DevOps: introducing infrastructure-as-code. In: IEEE/ACM International Conference on Software Engineering (Companion volume), pp. 497–498 (2017)

dal Bianco, V., Myllärniemi, V., Komssi, M., Raatikainen, M.: The role of platform boundary resources in software ecosystems: a case study. In: IEEE/IFIP Conference on Software Architecture, pp. 11–20 (2014)

Bosch, J.: From software product lines to software ecosystems. In: AMC International Conference Software Product Lines, pp. 111–119 (2009)

Brito, A., Valente, M.T., Xavier, L., Hora, A.: You broke my code: understanding the motivations for breaking changes in APIs. Empir. Softw. Eng. 25 (2), 1458–1492 (2019). https://doi.org/10.1007/s10664-019-09756-z

Article   Google Scholar  

Burns, C., Ferreira, J., Hellmann, T.D., Maurer, F.: Usable results from the field of API usability: a systematic mapping and further analysis. In: IEEE Symposium on Visual Languages and Human-Centric Computing, pp. 179–182 (2012)

Cummaudo, A., Vasa, R., Grundy, J.: What should I document? A preliminary systematic mapping study into API documentation knowledge. In: ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (2019)

De, B.: API Management. Apress, Berkeley (2017). https://doi.org/10.1007/978-1-4842-1305-6

Book   Google Scholar  

De Lima Fontao, A., Dos Santos, R., Dias-Neto, A.: Mobile software ecosystem (MSECO): a systematic mapping study. Int. Comput. Softw. Appl. Conf. 2 , 653–658 (2015)

Dig, D., Johnson, R.: How do APIs evolve? A story of refactoring. J. Softw. Maint. Evol. Res. Pract. 18 (2), 83–107 (2006)

Espinha, T., Zaidman, A., Gross, H.: Web API growing pains: loosely coupled yet strongly tied. J. Syst. Softw. 100 , 27–43 (2015)

Henning, M.: API design matters. ACM Queue 5 (4), 24–36 (2007)

Hora, A., Robbes, R., Valente, M.T., Anquetil, N., Etien, A., Ducasse, S.: How do developers react to API evolution? A large-scale empirical study. Software Qual. J. 26 (1), 161–191 (2016). https://doi.org/10.1007/s11219-016-9344-4

ISO/IEC: 25010:2011, Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) - system and software quality models (2011)

Jezek, K., Dietrich, J., Brada, P.: How Java APIs break - an empirical study. Inf. Softw. Technol. 65 , 129–146 (2015)

Joutsenlahti, J., Lehtonen, T., Raatikainen, M., Kettunen, E., Mikkonen, T.: Challenges and governance solutions for data science services based on open data and APIs. In: IEEE/ACM 1st Workshop on AI Engineering - Software Engineering for AI of International Conference on Software Engineering (2021)

Manikas, K.: Revisiting software ecosystems research: a longitudinal literature study. J. Syst. Softw. 117 , 84–103 (2016)

Murphy, L., Alliyu, T., Macvean, A., Kery, M.B., Myers, B.A.: Preliminary analysis of REST API style guidelines. Ann Arbor 1001 , 48109 (2017)

Murphy, L., Kery, M.B., Alliyu, O., Macvean, A., Myers, B.A.: API designers in the field: design practices and challenges for creating usable APIs. In: IEEE Symposium on Visual Languages and Human-Centric Computing, pp. 249–258 (2018)

Myers, B.A., Stylos, J.: Improving API usability. Commun. ACM 59 (6), 62–69 (2016)

Myllärniemi, V., Kujala, S., Raatikainen, M., Sevońn, P.: Development as a journey: factors supporting the adoption and use of software frameworks. Journal of Software Engineering Research and Development 6 (1), 1–22 (2018). https://doi.org/10.1186/s40411-018-0050-8

Nybom, K., Ashraf, A., Porres, I.: A systematic mapping study on API documentation generation approaches. In: Euromicro Conference on Software Engineering and Advanced Applications, pp. 462–469 (2018)

Raatikainen, M., Tiihonen, J., Männistö, T.: Software product lines and variability modeling: a tertiary study. J. Syst. Softw. 149 , 485–510 (2019)

Rauf, I., Troubitsyna, E., Porres, I.: Systematic mapping study of API usability evaluation methods. Comput. Sci. Rev. 33 , 49–68 (2019)

Robillard, M.P.: What makes APIs hard to learn? Answers from developers. IEEE Softw. 26 (6), 27–34 (2009)

Soldani, J., Tamburri, D., Van Den Heuvel, W.J.: The pains and gains of microservices: a systematic grey literature review. J. Syst. Softw. 146 , 215–232 (2018)

Yin, R.K.: Case Study Research: Design and Methods. Sage (2014)

Download references

Acknowledgements

We acknowledge the financial support of Business Finland as a part of 4APIs project.

Author information

Authors and affiliations.

University of Helsinki, Helsinki, Finland

Mikko Raatikainen, Elina Kettunen & Tommi Mikkonen

Digia Plc, Turku, Finland

Ari Salonen

F-Secure Plc, Helsinki, Finland

Marko Komssi

Solita Ltd., Tampere, Finland

Timo Lehtonen

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Mikko Raatikainen .

Editor information

Editors and affiliations.

Institute of Information Systems Engineering, Technische Universität Wien, Vienna, Austria

Stefan Biffl

University of Castilla-La Mancha, Albacete, Spain

Elena Navarro

Department of Computer Science, Linnaeus University, Växjö, Sweden

Design and Engineering, Mälardalen University, Västerås, Sweden

Marjan Sirjani

Politecnico di Milano, Milano, Italy

Raffaela Mirandola

KU Leuven, Leuven, Belgium

Danny Weyns

Rights and permissions

Reprints and permissions

Copyright information

© 2021 Springer Nature Switzerland AG

About this paper

Cite this paper.

Raatikainen, M., Kettunen, E., Salonen, A., Komssi, M., Mikkonen, T., Lehtonen, T. (2021). State of the Practice in Application Programming Interfaces (APIs): A Case Study. In: Biffl, S., Navarro, E., Löwe, W., Sirjani, M., Mirandola, R., Weyns, D. (eds) Software Architecture. ECSA 2021. Lecture Notes in Computer Science(), vol 12857. Springer, Cham. https://doi.org/10.1007/978-3-030-86044-8_14

Download citation

DOI : https://doi.org/10.1007/978-3-030-86044-8_14

Published : 26 August 2021

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-86043-1

Online ISBN : 978-3-030-86044-8

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

To read this content please select one of the options below:

Please note you do not have access to teaching notes, a study on application programming interface recommendation: state-of-the-art techniques, challenges and future directions.

Library Hi Tech

ISSN : 0737-8831

Article publication date: 18 August 2022

Issue publication date: 1 June 2023

This study aims to identify the developer’s objectives, current state-of-the-art techniques, challenges and performance evaluation metrics, and presents outlines of a knowledge-based application programming interfaces (API) recommendation system for the developers. Moreover, the current study intends to classify current state-of-the-art techniques supporting automated API recommendations.

Design/methodology/approach

In this study, the authors have performed a systematic literature review of studies, which have been published between the years 2004–2021 to achieve the targeted research objective. Subsequently, the authors performed the analysis of 35 primary studies.

The outcomes of this study are: (1) devising a thematic taxonomy based on the identified developers’ challenges, where mashup-oriented APIs and time-consuming process are frequently encountered challenges by the developers; (2) categorizing current state-of-the-art API recommendation techniques (i.e. clustering techniques, data preprocessing techniques, similarity measurements techniques and ranking techniques); (3) designing a taxonomy based on the identified objectives, where accuracy is the most targeted objective in API recommendation context; (4) identifying a list of evaluation metrics employed to assess the performance of the proposed techniques; (5) performing a SWOT analysis on the selected studies; (6) based on the developer’s challenges, objectives and SWOT analysis, presenting outlines of a recommendation system for the developers and (7) delineating several future research dimensions in API recommendations context.

Research limitations/implications

This study provides complete guidance to the new researcher in the context of API recommendations. Also, the researcher can target these objectives (accuracy, response time, method recommendation, compatibility, user requirement-based API, automatic service recommendation and API location) in the future. Moreover, the developers can overcome the identified challenges (including mashup-oriented API, Time-consuming process, learn how to use the API, integrated problem, API method usage location and limited usage of code) in the future by proposing a framework or recommendation system. Furthermore, the classification of current state-of-the-art API recommendation techniques also helps the researchers who wish to work in the future in the context of API recommendation.

Practical implications

This study not only facilitates the researcher but also facilitates the practitioners in several ways. The current study guides the developer in minimizing the development time in terms of selecting relevant APIs rather than following traditional manual selection. Moreover, this study facilitates integrating APIs in a project. Thus, the recommendation system saves the time for developers, and increases their productivity.

Originality/value

API recommendation remains an active area of research in web and mobile-based applications development. The authors believe that this study acts as a useful tool for the interested researchers and practitioners as it will contribute to the body of knowledge in API recommendations context.

• Application programming interface
• Systematic review
• API recommendation system
• API developer challenges

Nawaz, M.S. , Khan, S.U.R. , Hussain, S. and Iqbal, J. (2023), "A study on application programming interface recommendation: state-of-the-art techniques, challenges and future directions", Library Hi Tech , Vol. 41 No. 2, pp. 355-385. https://doi.org/10.1108/LHT-02-2022-0103

Emerald Publishing Limited

Copyright © 2022, Emerald Publishing Limited

Related articles

We’re listening — tell us what you think, something didn’t work….

Report bugs here

All feedback is valuable

Please share your general feedback

Join us on our journey

Platform update page.

Visit emeraldpublishing.com/platformupdate to discover the latest news and updates

Questions & More Information

Answers to the most commonly asked questions here

• Get IGI Global News

• All Products
• Book Chapters
• Journal Articles
• Video Lessons
• Teaching Cases
• Recommend to Librarian
• Recommend to Colleague
• Fair Use Policy

• Access on Platform

Export Reference

• e-Journal Collection
• e-Book Collection Select
• Business Knowledge Solutions e-Journal Collection

Application Programming Interface (API) Research: A Review of the Past to Inform the Future

Introduction.

Software has become indispensable in today’s business environment. It has become challenging to envisage business success without software. Given this, there have been advances in the field of software development on how software is developed (Kroll, Richardson, Prikladnicki, & Audy, 2018), and tested (Barr, Harman, McMinn, Shahbaz, & Yoo, 2015). Software development over the years is perceived as a daunting task (Park & Bae, 2011) and demands a lot of activities (Tang, Aleti, Burge, & Vliet, 2010). Hence, developers are continually exploring innovations that will aid the software development process. Application Programming Interfaces (here after referred to as APIs) are one of such innovations in the software development domain. APIs form an integral component of the software ecosystem (Manikas, 2016). These software ecosystems have become an ideal way of constructing large software solutions on top of a common technology platform (Manikas & Hansen, 2013).

Historically, APIs have been there since the advent of personal computers. APIs primarily existed for the exchange between two or more programs (IBM, 2016). The emergence of APIs on the web (what is mostly referred to as web APIs) was, however, witnessed around the year 2000. Since then, APIs have received considerable interest from practitioners and researchers to the extent that some pundits argue that we now live in the API economy. This position is supported by the fact that we have become interconnected like never before; and APIs primarily power this interconnection of people, applications and systems. As such, APIs are becoming the fibre of the digital ecosystem that seeks to interconnect businesses and economies to create value and develop more capabilities (Abigee, 2016; Anuff, 2017). The mobile application market, one of the fastest growing areas in information technology, makes use of APIs a lot (Linares-Vásquez et al., 2013; Bavota et al., 2015). Developers of mobile applications primarily rely on APIs to provide reliable and interoperable applications. Despite these developments, researchers are yet to take ascertain the current state of API research in order to provide insights for future research. The current study, therefore, seeks to provide an overview of extant API research to determine the state of the research and steer future research.

Various authors have explained what APIs are, from diverse perspectives. While some authors have given a concrete definition for APIs, others prefer to give clues by providing the attributes or characteristics of APIs. These definitions can be considered either from a technical viewpoint (e.g. Niu et al. 2016; Shatnawi et al. 2016) or from a sociotechnical viewpoint, (e.g Abigee, 2016; Anuff, 2017; Zachariadis & Ozcan, 2017; Ofoeda & Boateng, 2018). Arguably, a better comprehension of APIs goes beyond the technical definition and overlaps into a broader concept where perspectives of users and practitioners are considered. Niu et al. (2016) aver that APIs facilitate pragmatic reuse and improve the productivity of software development. Other authors define APIs as the collection of codes, packaged with interfaces that aid other developers to use it (Stylos & Myers, 2007).

Similarly, Qiu et al. (2016) posit that APIs support software reuse by providing pre-implemented functionalities; thus, reducing the effort and time programmers spend in developing software. The importance of interfaces to the software development process is very crucial. Past research has affirmed how vital interfaces have become in contemporary software development (Shepherd & Pollock, 2005; Robbes & Lungu, 2011; Manikas, 2016). Generally, the explanations mentioned above seem more technical and may be less comprehensible to a lay person. The other definitions of APIs which seem to be less technical argue that APIs provide a common ground for software to talk to each other (Anuff, 2017). This common ground enables different software to exchange information. Through the exchange of information, services between and within organizations, they can create value (Lyer & Subramaniam, 2015).

Complete Article List

Application Programming Interface (API) Research: A Review of the Past to Inform the Future

29  citations

View 1 citation excerpt

Cites background from "Application Programming Interface (..."

... It reduces the effort of reprogramming following changes in the scenario [54]. ...

22  citations

19  citations

7  citations

... , WEB and TMAS) are included to manage the patient requests, and application programmable interface (API) directs the server access, collects and delivers responses.(23) The SHES accessing via the internet with a secure sockets layer (SSL) implementation, and firewall for data protection between systems are introduced. ...

5  citations

6,406  citations

2,279  citations

1,866  citations

1,344  citations

1,331  citations

Related Papers (5)

Ask Copilot

Related papers

Contributing institutions

Related topics

• Registration
• Previous Venues
• Linnaeus University
• Complete Program
• Your Program
• Research Papers
• Industry Program
• Journal First
• Tool&Demos
• Workshops/Tutorials
• Diversity, Equity and Inclusion (DE&I)
• Doctoral Symposium
• JSS Special Issue
• ECSA 2021 Committees
• Organizing Committee
• Steering Committee
• Workshops/Tutorials Committee
• Track Committees
• Contributors
• People Index

Program Display Configuration

Mikko Raatikainen

Elina kettunen, ari salonen, marko komssi.

Tommi Mikkonen

University of helsinki, timo lehtonen, fri 17 sep displayed time zone: amsterdam, berlin, bern, rome, stockholm, vienna change.

Thank you for visiting nature.com. You are using a browser version with limited support for CSS. To obtain the best experience, we recommend you use a more up to date browser (or turn off compatibility mode in Internet Explorer). In the meantime, to ensure continued support, we are displaying the site without styles and JavaScript.

• View all journals
• My Account Login
• Explore content
• About the journal
• Publish with us
• Sign up for alerts
• Open access
• Published: 28 February 2020

Application programming interfaces for knowledge transfer and generation in the life sciences and healthcare

• Stephen K Woody 1 ,
• David Burdick 2 ,
• Hilmar Lapp   ORCID: orcid.org/0000-0001-9107-0714 3 &
• Erich S. Huang 1 , 4  

npj Digital Medicine volume  3 , Article number:  24 ( 2020 ) Cite this article

3121 Accesses

6 Citations

26 Altmetric

Metrics details

• Public health
• Translational research

A Publisher Correction to this article was published on 09 April 2020

This article has been updated

Storing very large amounts of data and delivering them to researchers in an efficient, verifiable, and compliant manner, is one of the major challenges faced by health care providers and researchers in the life sciences. The electronic health record (EHR) at a hospital or clinic currently functions as a silo, and although EHRs contain rich and abundant information that could be used to understand, improve, and learn from care as part learning health system access to these data is difficult, and the technical, legal, ethical, and social barriers are significant. If we create a microservice ecosystem where data can be accessed through APIs, these challenges become easier to overcome: a service-driven design decouples data from clients. This decoupling provides flexibility: different users can write in their preferred language and use different clients depending on their needs. APIs can be written for iOS apps, web apps, or an R library, and this flexibility highlights the potential ecosystem-building power of APIs. In this article, we use two case studies to illustrate what it means to participate in and contribute to interconnected ecosystems that powers APIs in a healthcare systems.

Introduction

In the late 19th and early 20th century as households became electrified for light, the concept of “appliances”—devices that might use electricity for other purposes, such as sewing machines and chafing dishes—was novel. A tally by the Southern California Edison Company reported that in 1904 there were 500 appliances in all of Southern California. 1 Surprisingly, “the appliance plug is conspicuously absent” from Thomas Edison’s myriad patents. 1 For decades, the principle means for connecting electrical devices was screwing them into the same Edison-type sockets used by light bulbs. This came with attendant inconveniences and hazards: for instance, connecting one’s flat iron meant that one would have to remove light bulb to do so, the power cord would become vexingly twisted when connecting it, and if the iron were dropped there was not an easily separable connection between the appliance and its power supply with the possibility of short circuit or shock. It was not until 1917, 37 years after Edison’s patent for the light bulb—that six manufacturers agreed on a standard receptacle for separable attachment plugs. 1

In healthcare and life sciences, we are currently living in an era analogous to the early days of electricity; an uncomfortable interregnum between the clear promise of health data appliances/applications for improving health and the difficult reality of our data is equivalent to one-off custom hard-wiring or twisted cords dangling from Edison screw-type sockets. Health data are not readily transmittable across diverse sources, systems, and countries, and are typically housed in monolithic servers cordoned by technical, legal, ethical, and social roadblocks. 2 While we are used to the myriad consumer “apps” that “plug-in” to the iOS or Android ecosystems, there is no equivalent in health care and the life sciences. Even when access to particular data is granted, making those data readily usable for the secondary purposes of generating and transferring knowledge is challenging. A widely held rule of thumb is that 80% of the time spent in creating an analytic data set is allocated to cleaning, linking, and merging data, while only 20% of the effort is applied to analyzing the data for insights or applying machine learning. 3 , 4

The idea of a data warehouse for health data, developed decades ago for periodic reporting, should be reevaluated as applications—programs that make those data usable or actionable on a routine basis. “Secondary” data transactions tied to analytic workflows or triggering actions are becoming as important as “primary” use. And we must think of data less as a “stash” to be accessed only periodically, but as a flow of information that is constantly being used—analogous to how we think of electricity being ubiquitously available for everyday tasks. Therefore, it becomes more important to think of a layer on top of data sources that make it more easily accessed by applications via “application programming interfaces (APIs)” to facilitate the transaction of data to applications (see Fig. 1 ). These ‘interfaces’ represent the data equivalent of the ubiquitous 110 v wall socket, and applications become the equivalent of physical appliances.

An application programming interface (API) abstraction layer on top of data sources can help make data accessible through applications to facilitate the transaction of data via APIs.

A recent elegant example of this concept embraces the HL7’s Fast Health Care Interoperability Resources (FHIR) standard 5 (which essentially provides a standardized container for data) to represent a patient’s entire EHR in temporal order (with all the idiosyncratic code in the EHR intact), and applied deep learning techniques to predict clinical outcomes (death, length of stay, and diagnoses) in a way that out-performed other clinically used predictive models. 6

Recently, the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare and Medicaid (CMS) announced a Proposed Rule intended to advance interoperability and support the access, exchange, and use of electronic health information. 7 The Proposed Rule calls on health IT developers to use APIs and mandates that information about the technology be “exchanged, accessed, and used without special effort.” 7

In this article, we illustrate what it means to participate in and contribute to interconnected ecosystems powered by APIs. We present two case studies of how we used APIs in an academic health system, and finally, present a way forward for developing and nurturing this ecosystem. The ONC proposed rule represents an important start; future practices and policies will need to advance the use of APIs for clinical data exchange from the electronic health record and other relevant data sources, not only for patient and clinician use, but also for other health care providers, payers, and for research.

Healthcare systems leaders who make decisions about IT teams and the IT teams themselves should rethink data infrastructure in healthcare so that modern applications and analytics can be delivered through APIs, services, and cloud-like environments. This will support the goal of facilitating knowledge generation while minimizing the burdens of navigating access to monolithic data silos.

A brief overview of APIs

APIs are analogous to standardized electrical sockets, but instead of electricity, APIs perform the service of moving data. APIs are software ports that provide secure routes for moving data around a network or the internet; they are a mechanism by which an external program invokes another program’s function or methods. Accordingly, moving to an IT strategy that supports APIs is important because it standardizes the “socket” for sharing and using data.

Case Study #1: data provenance solution at Duke using APIs and microservices

In response to an incident of research misconduct at Duke University where a researcher altered data sets, 8 our research team conducted a project called the “Duke Data Service” to capture data provenance from the time of data creation through to publication. Based on two of the authors’ early experience in developing a system for tracking provenance at Sage Bionetworks (where they have been working on the problem), we embarked on creating a solution using APIs and microservices. This was Duke’s first enterprise, service-based application, the first application designed and built from the ground up to implement a service-based architecture, and the first time we used cloud services as part of the deployment and execution process.

At Duke University, much of the original data surfaces in core labs across campus (e.g., next gen sequencing). To limit the opportunity to corrupt data, we set out to capture and “fingerprint” data at the earliest possible point in the process. Our intent was to automate the process of taking data off of the equipment, create a hash, and store the data in a secure storage system. On the deployment side, we used the Heroku platform. Execution services include Ruby (Rails), RabbitMQ, PostgreSQL, Neo4j and Elasticsearch. Adhering to a service-based architecture meant that we would encapsulate all functions within services with clearly defined APIs. (We posted all documentation on the GitHub repository https://github.com/Duke-Translational-Bioinformatics/duke-data-service ). Documenting a specification for each API is the genesis of each service. We used Blueprint ( https://apiblueprint.org ) to document our APIs and Dredd ( https://dredd.readthedocs.io/en/latest/ ) to test them. We automated the process of testing and deployment. Today, the APIs go through over 5000 tests prior to deployment. Once passed, the process deploys the code. This process improves quality and facilitates quick deployment of fixes and new functions.

Duke Data Service breaks down into the following functional categories:

Authorizations

Folders and files

Storage (Swift object storage)

Core facility workflow

The University IT group provides the authentication service for user and service accounts. The Data Service employs a project concept and provides folder structures and access management. In addition, the Data Service provides a flexible metadata layer allowing the user to store and query any desired metadata. OpenStack’s Swift object storage is our original storage implementation, however, we designed the Data Service to easily add new data storage options such as cloud object storage (Amazon’s S3), archive storage (Amazon’s Glacier), etc.

Our research community easily understands the base data services and file services grouped by project with some metadata. There is an easy-to-use mobile device and web-based interface allowing access to projects with folders and files. APIs are straightforward, documented with examples and easy to use. Using these basic storage services provides initial provenance. As data moves through various transitions and translations, researchers need a more sophisticated provenance capability. Based on the W3C standard for provenance ( https://www.w3.org/2001/sw/wiki/PROV ), we are adding new provenance services.

The result of our work is a service-based provenance storage called the Duke Data Service. The Duke Data Service provides, through a service-based API, access to significant storage (120 terabytes), and the ability to assign/move data from one custodian (for example, the core lab) to another (for example, a researcher). We recently added another storage provider, Dell/EMC’s Elastic Cloud Storage (1.8 petabytes) without affecting existing users and simply adding another storage option.

The Data Service team designed the services with the expectation that others outside of the Data Service team would eventually utilize Data Service’s capabilities. During the first seven months of 2019, the Data Service received on average 46,300 files per month totaling almost 7500 GB per month.

Because our solution used APIs and microservices, it enabled an ecosystem where others could build off our work. For example, the data-producing core labs at the Duke University Center for Genomics and Computational Biology (GCB), sought to better automate its genomics data management and delivery processes. GCB’s research IT group (note that this team is entirely separate from the team that built Duke Data Service), without our prompting, recognized that the Duke Data Service provides key enterprise-level infrastructure building blocks that enabled it to create an application on top of the Duke Data Service API that focuses on uploading, sharing, transferring, and downloading high-volume genomics data from a command-line shell environment. In essence, GCB has independently written a series of “appliances” or applications leveraging the Duke Data Service “sockets” or APIs. The applications were subsequently integrated into the core lab’s data generation and delivery pipeline. By connecting to the Duke Data Service for storage of laboratory output, it automatically starts a provenance chain for these data, one of our original motivating goals. The application created by the GCB team is written in the Python language, and thus uses a technology stack distinct from the Duke Data Service. Such loose coupling, and ability for client applications to use the technology stack most appropriate for them (Python is much more widely used in the computational genomics domain than, for example, Ruby), is among the key benefits enabled by a service-based architecture. In GCB’s latest release, they added a web-based user interface connecting into the same APIs making it even easier for the cores’ lab staff to manage data delivery, and for research labs to receive the data at the most useful location.

Data provenance API source code

Because data provenance is important for all research institutes, we share the source code, the architecture and the methods by which we are attempting to solve the problem publicly on Github ( https://github.com/Duke-Translational-Bioinformatics/duke-data-service ).

Case Study #2: providing up-to-date Institutional Review Board (IRB) information through APIs—an useful abstraction layer

A more recent implementation of an API strategy demonstrates the value of an API as an abstraction layer. Internal audit cited a department for not keeping access privileges to private health information (PHI) in sync with the IRB’s official record of key personnel. To address this issue, we created two API endpoints that provide the status of the IRB approval (active or not active) and a list of current key personnel (those that may access PHI). Our prior IRB system and database did not provide any programmatic mechanism or direct insight to this information. Moreover, understanding the IRB approval status was not as simple as looking up a status. There were other statuses that, in combination with the expiration data, indicated that the IRB approval was active.

Instead of replicating this business logic in multiple systems, we centralized it in the API. We were fortunate that a number of years ago we contracted with the IRB vendor to help us create an extract of the data into a reporting data mart, which was the source of data for the API. The reporting data mart is updated daily, which is adequate for our purposes. Systems that needed the active status of a protocol and the key personnel list can simply call the API. The API is REST-based and does not require the calling program to be written in any particular language. Most modern programming languages support REST calls.

Not only were we able to encapsulate the business logic, but during the implementation, we changed IRB vendors. The change involved creating a new reporting database and changes in logic determining if the IRB is active. We modified the API to access the new data mart and the business logic. No changes were necessary to any application using the API, and everything was completely transparent.

Implementation of this new API added an API manager or service bus, Kong. The API manager authenticates each call and performs message traffic regulation such as load balancing and throttling. The API manager provides greater insight into communication and message traffic.

On the user side, a few lines of code—without the need for a professional programmer—can be used to populate up-to-date IRB data even to database-style applications. In fact, most modern frameworks for API documentation now automatically provide code that can be readily used to access those APIs. 9

In this example, we see two clear benefits of the API model: (1) keeping IRB business logic out of other applications by centralizing it in one place and (2) isolation of the IRB application allowing us to swap IRB vendors without impacting applications using the API.

As with many institutions like Duke, there are API construction activities in many departments. These activities tend to be disjointed, lack common standards, and have no mechanisms for preventing redundancy. The next two major challenges we plan to address in institutionalizing the API-based architecture are (1) organizing information and documentation on APIs in a common location so others can search for and use existing APIs (rather than creating new APIs every time) and (2) improving the maturity of APIs.

To recall our earlier analogy using the 110 Volt AC socket, providing standardized and well-documented “data sockets” via APIs provides many benefits in healthcare and the life sciences that are similar to the benefits that sockets have provided for electrical appliances in our daily life.

Standardized API interfaces simplify building applications: as we note in our examples, once a uniform and documented set of APIs was created it became very easy for developers from an entirely different team than the API developers to create fit-for-purpose applications such as an application for delivering large next generation sequencing data to customers from a genomic core laboratory or incorporating up-to-date IRB status and key personnel to a research database.

Applications become easier to maintain: since applications are built against APIs, if the system behind the API interface layer changes, there are minimal if any changes the developer must make. To use the AC socket analogy, if you add solar panels to your house or your power company switches to a different plant, your microwave oven continues to function without any intervention. As noted in our IRB example, even though the underlying IRB system changed entirely, the were no changes necessary for the consumer of the API.

APIs encourage ecosystems: from the time of Edison on, standardized methods for storing and delivering electricity has encouraged an ecosystem of devices that make that electricity useful in our daily lives, whether via appliances or now, automobiles. As data acquires the same ubiquity and utility as electricity, APIs represent a standard for making data useful through applications. Alphabet, the parent company of Google, provides public access to close to 200 different APIs, many of which will be familiar to the reader (at least through apps such as Google Maps or Google Assistant), such as those for street view, directions, and search. While Google itself uses these APIs for its own apps, other companies use them as well through their own applications, such as Uber or AirBnB.

Assuming one accepts the general principle of APIs, an important issue to be addressed is the lack of data standards. This is a fair question and addresses a fundamental “chicken or the egg” problem in health informatics. Do we await standards before exposing them via application programming interfaces? Or do we “prime the pump” and begin exposing data via interfaces and allow standards to develop with increasing ubiquity and use of data? HL7’s FHIR standard is an important first step for health-related data and is widely embraced as a proposed standard even while its actual use is still very limited. In many ways, FHIR embraces many best practices learned from the widespread adoption of APIs outside of healthcare. One of the most important of these principles is providing human and machine-readable documentation of an API. Whether an API exposes data as XML (Extensible Markup Language), JSON (Javascript Object Notation), YAML (YAML Ain’t Markup Language), or Protobuf (Protocol Buffers), if it is readily parse-able, API documentation can make it relatively easy for application developers to consume those data. In fact, many modern frameworks for building APIs automatically generate documentation, and further, generate programmatic libraries such that programmers merely need to install a pre-built library to use an API. Therefore, all the tools to make an API immediately useable by someone else can be seamlessly produced as artifacts of building an API.

This begs an additional consideration: the Google Maps API, as well-documented and understood as it may be, is not useable by a layperson; software engineers must write an application—whether it is the Google Maps app or the AirBnB app on one’s phone—to make it useful to non-programmers. Application programming interfaces are necessary, but not sufficient, for making data readily useable. Just as electricity requires engineers and manufacturers with special capabilities to produce refrigerators or plug-in hybrids, producers of health data APIs require counterparts with the skills to write health data applications for use cases such as AI-driven clinical decision support or clinical trial matching. In healthcare and the life sciences, creating this new category of application developers requires recognition of this need and a cultural evolution that embraces a new professional category of personnel who have both domain expertise in the health and life sciences and software engineering skills.

Some sectors in life sciences are building data ecosystems, for example, in 2015, the National Institutes for Health Big Data to Knowledge (NIH BD2K) Center for Big Data in Translational Genomics (CBDTG) pioneered the development of shared APIs to connect genomics repositories. 2 Genomic data sets suffered from siloed systems that lacked common standards across diverse and geographically disparate sites, and there were clear incentives for facilitating access to the data so they could be compared.

Our colleague, Amy Abernethy, notes in an AMIA keynote that “the more that we use data, the clearer the river of data gets”. 10 We suggest that APIs for life science and health data provide the wellspring for such a river. At the same time, APIs by themselves are not enough. Developers who are skilled at both creating and consuming APIs and are conversant in the health and life sciences are necessary too. As with any new technology, new job categories are essential to making them useful to our communities. Standards are necessary too, and the question arises whether standards need to occur first or whether increasing data liquidity will provide opportunity for the community to develop standards informed by real-world usage. If this is the case, we will also need to learn from our peers in the technology sector the best practices for API design and documentation that facilitate active use and a crowdsourcing of effective standards. FHIR represents a promising start in this direction.

Undoubtedly, significant culture change is required to build toward a vision of API-driven data interchange. Again, there is much to learn from the technology sector in observing the pace of innovation that has accompanied widespread adoption of APIs. Companies like Stripe or Twilio provide myriad customers capabilities for their apps via the Stripe payment or Twilio messaging APIs. Traditional industries such as automobile manufacturing or banking are responding to this by rapidly expanding their cohorts of API and application developers; it is clear that applications are the “appliances” of our time. Our experience in an academic health system is that API development is a means to begin developing an ecosystem and culture that focuses on the usage as opposed to the warehousing of data. No doubt, as with any culture change, it will take time to live up to the promise of APIs and applications in health, but the historical parallels of electrification and the tech sector’s API economy provide reassurance that the investment will be rewarded.

Data availability

For Duke Data Service, we posted all code and documentation on the GitHub repository https://github.com/Duke-Translational-Bioinformatics/duke-data-service .

Change history

16 february 2021.

A Correction to this paper has been published: https://doi.org/10.1038/s41746-020-0271-1

09 April 2020

Schroeder, F. E. H. More “Small Things Forgotten”: domestic electrical plugs and receptacles, 1881–1931. Technol. Cult. 27 , 525 (1986).

Article   Google Scholar  

Paten, B. et al. The NIH BD2K center for big data in translational genomics. J. Am. Med. Inform. Assoc. https://doi.org/10.1093/jamia/ocv047 (2015).

Press G. Cleaning big data: most time-consuming, least enjoyable data science task, survey says. Forbes . https://www.forbes.com/sites/gilpress/2016/03/23/data-preparation-most-time-consuming-least-enjoyable-data-science-task-survey-says/#6056275a6f63 (2018).

Lohr S. For Big-Data Scientists, ‘Janitor Work’ Is Key Hurdle to Insights. The New York Times . https://www.nytimes.com/2014/08/18/technology/for-big-data-scientists-hurdle-to-insights-is-janitor-work.html . Published on August 2014 (2018).

HL7 International. HL7 FHIR Realese 4. https://www.hl7.org/fhir/ .

Rajkomar, A. et al. Scalable and accurate deep learning with electronic health records. npj Digital Med. 1 , 18 (2018).

Office of the National Coordinator for Health Information Technology. 21st Centure Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule. https://www.healthit.gov/sites/default/files/nprm/ONCCuresActNPRM.pdf (2019).

Kaiser J. Potti found guilty of research misconduct. Science . https://doi.org/10.1126/science.aad7410 (2015).

Lin J. The Ultimate API Publisher’s Guide. Medium Best Practices. https://medium.com/better-practices/the-ultimate-api-publishers-guide-be74a2692326 (2018).

Versel N. 5 steps toward a learning health system: AMIA kicks off with a challenge for informaticians. Healthcare IT News . November 2014. https://www.healthcareitnews.com/news/5-steps-toward-learning-health-system (2020).

Download references

Acknowledgements

The Duke School of Medicine is the primary funder with support of an NIH Big Data to Knowledge grant (5U01EB020957), a Burroughs Wellcome grant (1014979) and CTSA support (5UL1TR002553). We wish to acknowledge Karen Staman for her editorial support.

Author information

Authors and affiliations.

Duke University School of Medicine, 701W. Main St, Durham NC, 27701, USA

Stephen K Woody & Erich S. Huang

Stratus Medicine, 920S. Holgate St, Suite 104, Seattle, WA, 98134, USA

David Burdick

Center for Genomic and Computational Biology, Duke University, 101 Science Drive, Durham, NC, 27708, USA

Hilmar Lapp

Duke Health, Duke Forge and Duke Crucible, Suite 401, Davison Building, 100 Trent Drive, Durham, NC, 27708, USA

Erich S. Huang

You can also search for this author in PubMed   Google Scholar

Contributions

All authors made substantial contributions to the conception and design of the work presented here, are responsible and accountable for the content of this manuscript, and helped draft of critically revise it. E.S.H. was involved in all projects presented as case studies and drafted the initial version of this paper. D.B. helped design and build elements of the Duke Data Service and was a member of the Sage team. S.K.W. was instrumental for both Duke Data Service, IRB case studies, and drafted and edited much of the paper. H.L. helped create the application for the Duke University Center for Genomics and Computational Biology that uses the Duke Data Center API, and he helped draft and edit that section.

Corresponding author

Correspondence to Erich S. Huang .

Ethics declarations

Competing interests.

S.K.W. has no conflicts of interest to disclose. D.B. is the CEO of Stratus Medicine. H.L. has no conflicts of interest to disclose. E.S.H. is a non-executive Founder of Stratus Medicine, kēlaHealth, and MedBlue Data.

Additional information

Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ .

Reprints and permissions

About this article

Cite this article.

Woody, S.K., Burdick, D., Lapp, H. et al. Application programming interfaces for knowledge transfer and generation in the life sciences and healthcare. npj Digit. Med. 3 , 24 (2020). https://doi.org/10.1038/s41746-020-0235-5

Download citation

Received : 13 September 2019

Accepted : 11 February 2020

Published : 28 February 2020

DOI : https://doi.org/10.1038/s41746-020-0235-5

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

This article is cited by

Post-covid-19 syndrome: leveraging the patient perspective and technological innovations to enable the delineation of effective treatments.

• Matthew T. Roe
• Bray Patrick-Lake
• Andrew C. von Eschenbach

Drugs (2021)

Quick links

• Explore articles by subject
• Guide to authors
• Editorial policies

Sign up for the Nature Briefing: Translational Research newsletter — top stories in biotechnology, drug discovery and pharma.

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

•  We're Hiring!
•  Help Center

Application Programming Interface (API)

• Most Cited Papers
• Most Downloaded Papers
• Newest Papers
• Save to Library
• Last »

Enter the email address you signed up with and we'll email you a reset link.

• Academia.edu Publishing
•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024