Application Programming Interfaces Usage Research Articles

SSDTutor: A feedback-driven intelligent tutoring system for secure software development

Application Programming Interfaces (APIs) in cryptography typically impose concealed usage constraints. The violations of these usage constraints can lead to software crashes or security vulnerabilities. Several professional tools can detect these constraints (API misuses) in cryptography; however, in the educational programs, the focus has been less on helping students implement an application without cryptographic API misuses that are caused by either a lack of cryptographic knowledge or programming mistakes. To address the problem, we present an intelligent tutoring approach SSDTutor for educating Secure Software Development. Our tutoring approach helps students or developers repair cryptographic API misuse defects by leveraging an automated program repair technique based on the usage patterns of cryptographic APIs. We studied the best practices of cryptographic implementations and encoded eight cryptographic API usage patterns. For quality feedback, we leverage a clone detection technique to recommend related feedback for helping students understand why their programs are incorrect, rather than blindly accepting repairs. We evaluated SSDTutor on 456 open source subject projects implemented with cryptographic APIs. SSDTutor successfully detected 1,553 out of 1,573 misuse defects with 98.9% accuracy and repaired 1,551 out of 1,573 misuse defects with 99.3% accuracy. In a user study involving 22 students, the participants reported that interactive SSDTutor's feedback recommendation could be valuable for novice students to learn about the correct usages of cryptography APIs.

RESTful API Analysis, Recommendation, and Client Code Retrieval

Numerous companies create innovative software systems using Web APIs (Application Programming Interfaces). API search engines and API directory services, such as ProgrammableWeb, Rapid API Hub, APIs.guru, and API Harmony, have been developed to facilitate the utilization of various APIs. Unfortunately, most API systems provide only superficial support, with no assistance in obtaining relevant APIs or examples of code usage. To better realize the “FAIR” (Findability, Accessibility, Interoperability, and Reusability) features for the usage of Web APIs, in this study, we developed an API inspection system (referred to as API Prober) to provide a new API directory service with multiple supplemental functionalities. To facilitate the findability and accessibility of APIs, API Prober transforms OAS (OpenAPI Specifications) into a graph structure and automatically annotates the semantic concepts using LDA (Latent Dirichlet Allocation) and WordNet. To enhance interoperability, API Prober also classifies APIs by clustering OAS documents and recommends alternative services to be substituted or merged with the target service. Finally, to support reusability, API Prober makes it possible to retrieve examples of API utilization code in Java by parsing source code in GitHub. The experimental results demonstrate the effectiveness of the API Prober in recommending relevant services and providing usage examples based on real-world client code. This research contributes to providing viable methods to appropriately analyze and cluster Web APIs, and recommend APIs and client code examples.

Software Components and Product Variety in a Platform Ecosystem: A Dynamic Network Analysis of WordPress

Software components such as application programming interfaces (APIs) provided by external developers are vital to online digital platforms. Although APIs generally increase the variety of products according to anecdote, the precise relationship between the categories of APIs and product variety is not yet known. We find that APIs, regarding their use frequency, are categorized into three groups. The core is a group of frequently used APIs, whereas the periphery is a group of sparsely used APIs. In a large and mature platform ecosystem, an additional group of APIs, the regular core, mainly provided by third-party developers, emerges. APIs in the regular core are the main driver of product variety. However, we also find that the strength of this effect diminishes in a newly created product category when most of the new products are built by duplicating the usage of APIs from other products. A platform owner can stimulate developers’ creativity by acting as a bridge between digital product providers and third-party developers. It can collect functional needs from third-party developers and then share them with product providers. Therefore, the latter can build APIs that developers need.

Assisting Example-Based API Misuse Detection via Complementary Artificial Examples

Application Programming Interfaces (APIs) allow their users to reuse existing software functionality without implementing it by themselves. However, using external functionality can come at a cost. Because developers are decoupled from the API’s inner workings, they face the possibility of misunderstanding, and therefore misusing APIs. Prior research has proposed state-of-the-art example-based API misuse detectors that rely on existing API usage examples mined from existing code bases. Intuitively, without a varied dataset of API usage examples, it is challenging for the example-based API misuse detectors to differentiate between infrequent but correct API usages and API misuses. Such mistakes lead to false positives in the API misuse detection results, which was reported in a recent study as a major limitation of the state-of-the-art. To tackle this challenge, in this paper, we first undertake a qualitative study of 384 falsely detected API misuses. We find that around one third of the false-positives are due to missing alternative correct API usage examples. Based on the knowledge gained from the qualitative study, we uncover five patterns which can be followed to generate artificial examples for complementing existing API usage examples in the API misuse detection. To evaluate the usefulness of the generated artificial examples, we apply a state-of-the-art example-based API misuse detector on 50 open source Java projects. We find that our artificial examples can complement the existing API usage examples by preventing the detection of 55 false API misuses. Furthermore, we conduct a pre-designed experiment in an automated API misuse detection benchmark (MUBench), in order to evaluate the impact of generated artificial examples on recall. We find that the API misuse detector covers the same true positive results with and without the artificial example, i.e., obtains the same recall of 94.7 percent. Our findings highlight the potential of improving API misuse detection by pattern-guided source code transformation techniques.

Highlighting Current Issues in API Usage Mining to Enhance Software Reusability

The sheer amount of open source codes made available in code repositories and code search engines along with the rapidly increasing releases of Application Programming Interfaces (APIs) have made code devel- opment process easier for programmers. However, learning how to use the elements of an API properly is both challenging and requires learning curve. Mining the available client and test codes can help programmers to iden- tify the best practices in using these APIs. In this paper, we investigate the API usage mining to identify open issues for the researchers. In particular, we make a theoretical comparison of the API usage pattern mining and highlight unresolved issues along with proper suggestions to address them.

APIfix: output-oriented program synthesis for combating breaking changes in libraries

Use of third-party libraries is extremely common in application software. The libraries evolve to accommodate new features or mitigate security vulnerabilities, thereby breaking the Application Programming Interface(API) used by the software. Such breaking changes in the libraries may discourage client code from using the new library versions thereby keeping the application vulnerable and not up-to-date. We propose a novel output-oriented program synthesis algorithm to automate API usage adaptations via program transformation. Our aim is not only to rely on the few example human adaptations of the clients from the old library version to the new library version, since this can lead to over-fitting transformation rules. Instead, we also rely on example usages of the new updated library in clients, which provide valuable context for synthesizing and applying the transformation rules. Our tool APIFix provides an automated mechanism to transform application code using the old library versions to code using the new library versions - thereby achieving automated API usage adaptation to fix the effect of breaking changes. Our evaluation shows that the transformation rules inferred by APIFix achieve 98.7% precision and 91.5% recall. By comparing our approach to state-of-the-art program synthesis approaches, we show that our approach significantly reduces over-fitting while synthesizing transformation rules for API usage adaptations.

A Systematic Review of API Evolution Literature

Recent software advances have led to an expansion of the development and usage of application programming interfaces (APIs). From millions of Android packages (APKs) available on Google Store to millions of open-source packages available in Maven, PyPI, and npm, APIs have become an integral part of software development. Like any software artifact, software APIs evolve and suffer from this evolution. Prior research has uncovered many challenges to the development, usage, and evolution of APIs. While some challenges have been studied and solved, many remain. These challenges are scattered in the literature, which hides advances and cloaks the remaining challenges. In this systematic literature review on APIs and API evolution, we uncover and describe publication trends and trending topics. We compile common research goals, evaluation methods, metrics, and subjects. We summarize the current state-of-the-art and outline known existing challenges as well as new challenges uncovered during this review. We conclude that the main remaining challenges related to APIs and API evolution are (1) automatically identifying and leveraging factors that drive API changes, (2) creating and using uniform benchmarks for research evaluation, and (3) understanding the impact of API evolution on API developers and users with respect to various programming languages.

Does TDWG Need an API Design Guideline?

RESTful APIs (REpresentational State Transfer Application Programming Interfaces) are the most commonly used mechanism for biodiversity informatics databases to provide open access to their content. In its simplest form an API provides an interface based on the HTTP protocol whereby any client can perform an action on a data resource identified by a URL using an HTTP verb (GET, POST, PUT, DELETE) to specify the intended action. For example, a GET request to a particular URL (informally called an endpoint) will return data to the client, typically in JSON format, which the client converts to the format it needs. A client can either be custom written software or commonly used programs for data analysis such as R (programming language), Microsoft Excel (everybody’s favorite data management tool), OpenRefine, or business intelligence software. APIs are therefore a valuable mechanism for making biodiversity data FAIR (findable, accessible, interoperable, reusable). There is currently no standard specifying how RESTful APIs should be designed, resulting in a variety of URL and response data formats for different APIs. This presents a challenge for API users who are not technically proficient or familiar with programming if they have to work with many different and inconsistent data sources. We undertook a brief review of eight existing APIs that provide data about taxa to assess consistency and the extent to which the Darwin Core standard (Wieczorek et al. 2021) for data exchange is applied. We assessed each API based on aspects of URL construction and the format of the response data (Fig. 1). While only cursory and limited in scope, our survey suggests that consistency across APIs is low. For example, some APIs use nouns for their endpoints (e.g. ‘taxon’ or ‘species’), emphasising their content, whereas others use verbs (e.g. ‘search’), emphasising their functionality. Response data seldom use Darwin Core terms (two out of eight examples) and a wide range of terms can be used to represent the same concept (e.g. six different terms are used for dwc:scientificNameAuthorship). Terms that can be considered metadata for a response, such as pagination details, also vary considerably. Interestingly, the public interfaces for the majority of APIs assessed do not provide POST, PUT or DELETE endpoints that modify the database. POST is only used for providing more detailed request bodies to retrieve data than possible with GET. This indicates the primary use of APIs by biodiversity informatics platforms for data sharing. An API design guideline is a document that provides a set of rules or recommendations for how APIs should be designed in order to improve their consistency and useability. API design guidelines are typically created by particular organizations to standardize API development within the organization, or as a guideline for programmers using an organization’s software to build APIs (e.g., Microsoft and Google). The API Stylebook is an online resource that provides access to a wide range of existing design guidelines, and there is an abundance of other resources available online. This presentation will cover some of the general concepts of API design, demonstrate some examples of how existing APIs vary, and discuss potential options to encourage standardization. We hope our analysis, the available body of knowledge on API design, and the collective experience of the biodiversity informatics community working with APIs may help answer the question “Does TDWG need an API design guideline?”

ProSy: API-Based Synthesis with Probabilistic Model

Program synthesis is an exciting topic that desires to generate programs satisfying user intent automatically. But in most cases, only small programs for simple or domain-specific tasks can be synthesized. The major obstacle of synthesis lies in the huge search space. A common practice in addressing this problem is using a domain-specific language, while many approaches still wish to synthesize programs in general programming languages. With the rapid growth of reusable libraries, component-based synthesis provides a promising way, such as synthesizing Java programs which are only composed of APIs (application programming interfaces). However, the efficiency of searching for proper solutions for complex tasks is still a challenge. Given an unfamiliar programming task, programmers would search for API usage knowledge from various coding resources to reduce the search space. Considering this, we propose a novel approach named ProSy to synthesize API-based programs in Java. The key novelty is to retrieve related knowledge from Javadoc and Stack Overflow and then construct a probabilistic reachability graph. It assigns higher probabilities to APIs that are more likely to be used in implementing the given task. In the synthesis process, the program sketch with a higher probability will be considered first; thus, the number of explored reachable paths would be decreased. Some extension and optimization strategies are further studied in the paper. We implement our approach and conduct several experiments on it. We compare ProSy with SyPet and other state-of-the-art API-based synthesis approaches. The experimental results show that ProSy reduces the synthesis time of SyPet by up to 80%.

APISonar: Mining API usage examples

AbstractDevelopers spend a significant part of their time searching for code examples on the web. Often, they look for Application Programming Interface (API) usage examples, that is, how to use APIs provided by libraries and frameworks. For this purpose, several programming websites are available. Some programming websites provide manually created examples: unfortunately, as millions of APIs are available nowadays, they do not cover the majority of the APIs. To alleviate this limitation, other programming websites focus on automatically mining API usage examples from code repositories. To the best of our knowledge, however, these solutions are still very limited: they often present poor, duplicated, and similar API usage examples. In this article, we propose an approach, APISonar, to automatically mine API usage examples from code repositories. Our approach aims to overcome the limitations of current solutions: we focus on presenting readable and reusable API usage examples. We analyze millions of source files provided by 4486 software projects hosted on GitHub. Based on this data, we extract 11 million API usage examples about 1.5 million distinct APIs. We evaluate APISonar by assessing its quality and usage. We show that APISonar is a competitive solution, providing the best API examples in terms of readability and reusability, as compared with popular programming websites. Moreover, despite being a novel website, APISonar attracted a significant amount of users in a short period (3.7K users from 119 countries during 5 months). APISonar is available at www.apisonar.com.

Studying the Relationship Between the Usage of APIs Discussed in the Crowd and Post-Release Defects

Software development nowadays is heavily based on libraries, frameworks and their proposed Application Programming Interfaces (APIs). However, due to challenges such as the complexity and the lack of documentation, these APIs may introduce various obstacles for developers and common defects in software systems. To resolve these issues, developers usually utilize Question and Answer (Q&A) websites such as Stack Overflow by asking their questions and finding proper solutions for their problems on APIs. Therefore, these websites have become inevitable sources of knowledge for developers, which is also known as the crowd knowledge.However, the relation of this knowledge to the software quality has never been adequately explored before. In this paper, we study whether using APIs which are challenging according to the discussions of the Stack Overflow is related to code quality defined in terms of post-release defects. To this purpose, we define the concept of challenge of an API, which denotes how much the API is discussed in high-quality posts on Stack Overflow. Then, using this concept, we propose a set of products and process metrics. We empirically study the statistical correlation between our metrics and post-release defects as well as added explanatory and predictive power to traditional models through a case study on five open source projects including Spring, Elastic Search, Jenkins, K-8 Mail Android Client, and OwnCloud Android client.Our findings reveal that our metrics have a positive correlation with post-release defects which is comparable to known high-performance traditional process metrics, such as code churn and number of pre-release defects. Furthermore, our proposed metrics can provide additional explanatory and predictive power for software quality when added to the models based on existing products and process metrics. Our results suggest that software developers should consider allocating more resources on reviewing and improving external API usages to prevent further defects.

API Misuse Detection in C Programs: Practice on SSL APIs

Libraries offer reusable functionality through Application Programming Interfaces (APIs) with usage constraints such as call conditions or orders. Constraint violations, i.e. API misuses, commonly lead to bugs and security issues. Although researchers have developed various API misuse detectors in the past few decades, recent studies show that API misuse is prevalent in real-world projects, especially for secure socket layer (SSL) certificate validation, which is completely broken in many security-critical applications and libraries. In this paper, we introduce SSLDoc to effectively detect API misuse bugs, specifically for SSL API libraries. The key insight behind SSLDoc is a constraint-directed static analysis technique powered by a domain-specific language (DSL) for specifying API usage constraints. Through studying real-world API misuse bugs, we propose ISpec DSL, which covers majority types of API usage constraints and enables simple but precise specification. Furthermore, we design and implement SSLDoc to automatically parse ISpec into checking targets and employ a static analysis engine to identify potential API misuses and prune false positives with rich semantics. We have instantiated SSLDoc for OpenSSL APIs and applied it to large-scale open-source programs. SSLDoc found 45 previously unknown security-sensitive bugs in OpenSSL implementation and applications in Ubuntu. Up to now, 35 have been confirmed by the corresponding development communities and 27 have been fixed in master branch.

APIUaaS: a reference architecture for facilitating API usage from a data analytics perspective

Source code examples are key resources for software developers to learn application programming interfaces (APIs) and to understand corresponding usage patterns. Developers usually have to utilise, evaluate and understand code examples from multiple sources, which involve heavy manually processing efforts. To reduce such efforts, there has been growing interest in developing source code mining and recommendation systems. This study proposes API usage as a service (APIUaaS), a reference architecture for facilitating API usage, which allows infrastructures to be built for recommending proper API code examples based on semi-automatic data analytics. This reference architecture contains five logical layers and six global-level architectural concerns. API queries are accepted from programmers, and corresponding code example candidates are extracted from the data sources layer. The detailed structural links between API elements and source codes are captured and stored in the data model & code assets layer. During the recommendation phase, API usages mining, clustering and ranking algorithms are enabled in the knowledge discover & intelligent model layer. Services such as code assist and bug detection are assembled in the API usage services layer. Finally, the authors evaluate APIUaaS from three perspectives: rationality, feasibility, and usability.

Social media data archives in an API-driven world

In this article, we explore the long-term preservation implications of application programming interfaces (APIs) which govern access to data extracted from social media platforms. We begin by introducing the preservation problems that arise when APIs are the primary way to extract data from platforms, and how tensions fit with existing models of archives and digital repository development. We then define a range of possible types of API users motivated to access social media data from platforms and consider how these users relate to principles of digital preservation. We discuss how platforms’ policies and terms of service govern the set of possibilities for access using these APIs and how the current access regime permits persistent problems for archivists who seek to provide access to collections of social media data. We conclude by surveying emerging models for access to social media data archives found in the USA, including community driven not-for-profit community archives, university research repositories, and early industry–academic partnerships with platforms. Given the important role these platforms occupy in capturing and reflecting our digital culture, we argue that archivists and memory workers should apply a platform perspective when confronting the rich problem space that social platforms and their APIs present for the possibilities of social media data archives, asserting their role as “developer stewards” in preserving culturally significant data from social media platforms.

Why do they ask? An exploratory study of crowd discussions about Android application programming interface in stack overflow

Nowadays, more and more Android developers prefer to seek help from Q&A website like Stack Overflow, despite the rich official documentation. Several researches have studied the limitations of the official application programming interface (API) documentations and proposed approaches to improve them. However, few of them digged into the requirements of the third-party developers to study this. In this work, we gain insight into this question from multidimensional perspectives of API developers and API users by a kind of cross-validation. We propose a hybrid approach, which combines manual inspection on artifacts and online survey on corresponding developers, to explore the different focus between these two types of stakeholders. In our work, we manually inspect 1000 posts and receive 319 questionnaires in total. Through the mutual verification of the inspection and survey process, we found that the users are more concerned with the usage of API, while the official documentation mainly provides functional description. Furthermore, we identified 9 flaws of the official documentation and summarized 12 aspects (from the content to the representation) for promotion to improve the official API documentations.

Generative API usage code recommendation with parameter concretization

Many programming languages and development frameworks have extensive libraries (e.g., JDK and Android libraries) that ease the task of software engineering if used effectively.With numerous library classes and sometimes intricate API (application programming interface) usage constraints, programmers often have difficulty remembering the library APIs and/or using them correctly.This study addresses this problem by developing an engine called DeepAPIRec, which automatically recommends the API usage code. Compared to the existing proposals, our approach distinguishes itself in two ways. First, it is based on a tree-based long short-term memory (LSTM) neural network inspired by recent developments in the machine-learning community. A tree-based LSTM neural network allows us to model and reason about variable-length, preceding and succeeding code contexts, and to make precise predictions. Second, we apply data-flow analysis to generate concrete parameters for the API usage code, which not only allows us to generate complete code recommendations but also improves the accuracy of the learning results according to the tree-based LSTM neural network. Our approach has been implemented for supporting Java programs. Our experimental studies on the JDK library show that at statement-level recommendations, DeepAPIRec can achieve a top-1 accuracy of about 37% and a top-5 accuracy of about 64%, which are significantly better than the existing approaches.Our user study further confirms that DeepAPIRec can help developers to complete a segment of code faster and more accurately as compared to IntelliJ IDEA.

CAPS: a supervised technique for classifying Stack Overflow posts concerning API issues

The design and maintenance of APIs (Application Programming Interfaces) are complex tasks due to the constantly changing requirements of their users. Despite the efforts of their designers, APIs may suffer from a number of issues (such as incomplete or erroneous documentation, poor performance, and backward incompatibility). To maintain a healthy client base, API designers must learn these issues to fix them. Question answering sites, such as Stack Overflow (SO), have become a popular place for discussing API issues. These posts about API issues are invaluable to API designers, not only because they can help to learn more about the problem but also because they can facilitate learning the requirements of API users. However, the unstructured nature of posts and the abundance of non-issue posts make the task of detecting SO posts concerning API issues difficult and challenging. In this paper, we first develop a supervised learning approach using a Conditional Random Field (CRF), a statistical modeling method, to identify API issue-related sentences. We use the above information together with different features collected from posts, the experience of users, readability metrics and centrality measures of collaboration network to build a technique, called CAPS, that can classify SO posts concerning API issues. In total, we consider 34 features along eight different dimensions. Evaluation of CAPS using carefully curated SO posts on three popular API types reveals that the technique outperforms all three baseline approaches we consider in this study. We then conduct studies to find important features and also evaluate the performance of the CRF-based technique for classifying issue sentences. Comparison with two other baseline approaches shows that the technique has high potential. We also test the generalizability of CAPS results, evaluate the effectiveness of different classifiers, and identify the impact of different feature sets.

Detecting Proper SSL/TLS Implementation with Usage Patterns

The importance of secure communication over the Internet cannot be overstated because of the implications it has for ensuring privacy and safety for users. Much research has been done in this field of study, leading to the creation of the Secure Socket Layer (SSL) protocol and its successor—the Transport Layer Security (TLS) protocol. These protocols serve as a guide for implementing secure connections across the web and as such many libraries have been written to provide Application Programming Interface (API) for their implementation. However, many security risks have arisen due to improper usage of these libraries mainly due to the wrong sequence of API calls. It is also worth noting that the sequence of API calls might differ in certain situations, therefore adding to the level of complexity and increasing the chances of wrongful usage. In this paper, we present a method to detect proper API usage by defining them as usage patterns and testing them against proper implementation models.

MULAPI: Improving API method recommendation with API usage location

During the evolution of a software system, a large number of feature requests are continuously proposed by users. To implement these feature requests, developers often utilize existing third-party libraries and make use of Application Programming Interfaces (APIs) to accelerate the feature implementation process. However, it is not always obvious which API methods are suitable and where these API methods can be used in the target program.In this paper, we propose an approach, MULAPI (Method Usage and Location for API), to recommend API methods and figure out the API usage location where these API methods would be used. MULAPI employs feature location to identify feature related files as API usage location. Further, these feature related files are taken into account to recommend API methods by exploring the source code repository and API libraries as well. We evaluate MULAPI on more than 1000 feature requests of eight Java projects (Axis/Java, CXF, Hadoop Common, Hbase, Struts2, Hadoop HDFS, Hive and Hadoop Map/Reduce), and recommend API methods from ten third-party libraries. The empirical results show that MULAPI can accurately recommend API methods and usage location, and moreover, MULAPI improves the effectiveness of API method recommendation, compared with the state-of-the-art approach.

Improving access to API documentation for developers with Docs‐as‐Code‐as‐a‐service

ABSTRACTWeb Application Programming Interfaces (APIs) provide the connective tissue that developers need to integrate Internet services and create “software‐as‐a‐service” (SaaS) applications. To learn an API's usage, developers often turn to their web browsers to access documentation and try out APIs. However, traditional approaches to documentation present obstacles that can hamper API comprehension and developer productivity. To overcome these obstacles, practitioners are adopting a new approach called Docs‐as‐Code, in which documents are published with many of the same tools and practices used to deploy source code. In this paper, we present Dev Center, a system based in part on the Docs‐as‐Code framework and designed to provide ubiquitous access to a broad set of API documentation resources. Preliminary findings suggest that Dev Center could potentially improve API comprehension and developer productivity, while Docs‐as‐Code could benefit related research efforts.