API Elements Research Articles

RESTBERTa: a Transformer-based question answering approach for semantic search in Web API documentation

To enable machines to process state-of-practice Web API documentation, we propose a Transformer model for the generic task of identifying a Web API element within a syntax structure that matches a natural language query. We solve this semantic-search task with Transformer-based question answering and demonstrate the applicability of our approach to two different tasks, namely the discovery of endpoints and the identification of parameters in payload schemas. With samples from 2321 OpenAPI documentation, we prepare different datasets and fine-tune pre-trained BERT models to these two tasks. We evaluate the generalizability and the robustness of our fine-tuned models. We achieve accuracies of 81.95% for the parameter-matching and 88.44% for the endpoint-discovery task.

API-Related Developer Information Needs in Stack Overflow

Stack Overflow (SO) provides informal documentation for APIs in response to questions that express API related developer needs. Navigating the information available on SO and getting information related to a particular API and need is challenging due to the vast amount of questions and answers and the tag-driven structure of SO. In this paper we focus on identifying and classifying fine-grained developer needs expressed in sentences of API-related SO questions, as well as the specific information types used to express such needs, and the different roles APIs play in these questions and their answers. We derive a taxonomy, complementing existing ones, through an empirical study of 266 SO posts. We then develop and evaluate an approach for the automated identification of the fine-grained developer needs in SO threads, which takes a thread as input and outputs the corresponding developer needs, the types of information expressing them, and the roles of API elements relevant to the needs. To show a practical application of our taxonomy, we introduce and evaluate an approach for the automated retrieval of SO questions, based on these developer needs.

API beauty is in the eye of the clients: 2.2 million Maven dependencies reveal the spectrum of client–API usages

Hyrum’s law states a common observation in the software industry: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody”. Meanwhile, recent research results seem to contradict this observation when they state that “for most APIs, there is a small number of features that are actually used”. In this work, we perform a large scale empirical study of client–API relationships in the Maven ecosystem, in order to investigate this seeming paradox between the observations in industry and the research literature.We study the 94 most popular libraries in Maven Central, as well as the 829,410 client artifacts that declare a dependency to these libraries and that are available in Maven Central, summing up to 2.2M dependencies. Our analysis indicates the existence of a wide spectrum of API usages, with enough clients, most API types end up being used at least once. Our second key observation is that, for all libraries, there is a small set of API types that are used by the vast majority of its clients. The practical consequences of this study are two-fold: (i) it is possible for API maintainers to find an essential part of their API on which they can focus their efforts; (ii) API developers should limit the public API elements to the set of features for which they are ready to have users.

From API to NLI: A new interface for library reuse

Developers frequently reuse APIs from existing libraries to implement certain functionality. However, learning APIs is difficult due to their large scale and complexity. In this paper, we design an abstract framework NLI2Code to ease the reuse process. Under the framework, users can reuse library functionalities with a high-level, automatically-generated NLI (Natural Language Interface) instead of the detailed API elements. The framework consists of three components: a functional feature extractor to summarize the frequently-used library functions in natural language form, a code pattern miner to give a code template for each functional feature, and a synthesizer to complete code patterns into well-typed snippets. From the perspective of a user, a reuse task under NLI2Code starts from choosing a functional feature and our framework will guide the user to synthesize the desired solution. We instantiated the framework as a tool to reuse Java libraries. The evaluation shows our tool can generate a high-quality natural language interface and save half of the coding time for newcomers to solve real-world programming tasks.

An Automated Approach for Constructing Framework Instantiation Documentation

A substantial effort, in general, is required for understanding APIs of application frameworks. High-quality API documentation may alleviate the effort, but the production of such documentation still poses a major challenge for modern frameworks. To facilitate the production of framework instantiation documentation, we hypothesize that the framework code itself and the code of existing instantiations provide useful information. However, given the size and complexity of existent code, automated approaches are required to assist the documentation production. Our goal is to assess an automated approach for constructing relevant documentation for framework instantiation based on source code analysis of the framework itself and of existing instantiations. The criterion for defining whether documentation is relevant would be to compare the documentation with an traditional framework documentation, considering the time spent and correctness during instantiation activities, information usefulness, complexity of the activity, navigation, satisfaction, information localization and clarity. We propose an automated approach for constructing relevant documentation for framework instantiation based on source code analysis of the framework itself and of existing instantiations. The proposed approach generates documentation in a cookbook style, where the recipes are programming activities using the necessary API elements driven by the framework features. We performed an empirical study, consisting of three experiments with 44 human subjects executing real framework instantiations aimed at comparing the use of the proposed cookbooks to traditional manual framework documentation (baseline). Our empirical assessment shows that the generated cookbooks performed better or, at least, with non-significant difference when compared to the traditional documentation, evidencing the effectiveness of the approach.

Automatically identifying valid API versions for software development tutorials on the Web

AbstractOnline tutorials are a valuable source of community‐created information used by numerous developers to learn new APIs and techniques. Once written, tutorials are rarely actively curated and can become dated over time. Tutorials often reference APIs that change rapidly, and deprecated classes, methods, and fields can render tutorials inapplicable to newer releases of the API. Newer tutorials may not be compatible with older APIs that are still in use.In this paper, we first empirically study the tutorial versioning problem, confirming its presence in popular tutorials on the Web. We subsequently propose a technique, based on similar techniques in the literature, for automatically detecting the applicable API version ranges of tutorials, given access to the official API documentation they reference. The proposed technique identifies each API mention in a tutorial and maps the mention to the corresponding API element in the official documentation. The version of the tutorial is determined by combining the version ranges of all of the constituent API mentions. Our technique's precision varies from 61% to 89% and recall varies from 42% to 84% based on different levels of granularity of API mentions and different problem constraints. We observe API methods are the most challenging to accurately disambiguate due to method overloading. As the API mentions in tutorials are often redundant, and each mention of a specific API element commonly occurs several times in a tutorial, the distance of the predicted version range from the true version range is low: 3.61 on average for the tutorials in our sample.

An Empirical Study on API Usages

API libraries provide thousands of APIs, and are essential in daily programming tasks. To understand their usages, it has long been a hot research topic to mine specifications that formally define legal usages for APIs. Furthermore, researchers are working on many other research topics on APIs. Although the research on APIs is intensively studied, many fundamental questions on APIs are still open. For example, the answers to open questions, such as which format can naturally define API usages and in which case, are still largely unknown. We notice that many such open questions are not concerned with concrete usages of specific APIs, but usages that describe how to use different types of APIs. To explore these questions, in this paper, we conduct an empirical study on API usages, with an emphasis on how different types of APIs are used. Our empirical results lead to nine findings on API usages. For example, we find that single-type usages are mostly strict orders, but multi-type usages are more complicated since they include both strict orders and partial orders. Based on these findings, for the research on APIs, we provide our suggestions on the four key aspects such as the challenges, the importance of different API elements, usage patterns, and pitfalls in designing evaluations. Furthermore, we interpret our findings, and present our insights on data sources, extraction techniques, mining techniques, and formats of specifications for the research of mining specifications.

On the use of replacement messages in API deprecation: An empirical study

Libraries are commonly used to support code reuse and increase productivity. As any other system, they evolve over time, and so do their APIs. Consequently, client applications should be updated to benefit from better APIs. To facilitate this task, API elements should always be deprecated with replacement messages. However, in practice, there are evidences that API elements are deprecated without these messages. In this paper, we study questions regarding the adoption of deprecation messages. Our goal is twofold: to measure the real usage of deprecation messages and to investigate whether a tool is needed to recommend them. We assess (i) the frequency of deprecated elements with replacement messages, (ii) the impact of software evolution on this frequency, and (iii) the characteristics of systems that deprecate API elements in a correct way. Our analysis on 622 Java and 229 C# systems shows that: (i) on the median, 66.7% and 77.8% of the API elements are deprecated with replacement messages per project, (ii) there is no major effort to improve deprecation messages, and (iii) systems that deprecated API elements with messages are different in terms of size and community. As a result, we provide the basis for creating a tool to support clients detecting missing deprecation messages.

Redocumenting APIs with crowd knowledge: a coverage analysis based on question types

Software libraries and frameworks play an important role in software system development. The appropriate usage of their functionalities/components through their APIs, however, is a challenge for developers. Usually, API documentation, when it exists, is insufficient to assist them in their programming tasks. There are few API documentation writers for the many potential readers, resulting in the lack of explanations and examples concerning different scenarios and perspectives. The interaction of developers on the Web, on the other hand, generates content concerning APIs from different perspectives, which can be used to document APIs, also known as crowd documentation. In this paper, we present a study regarding the knowledge generated by the crowd on the Stack Overflow question-and-answer website. Our main goal is to understand how the crowd can contribute for API documentation on two programming tasks: how to implement a scenario using an API (how-to-do-it), and how to fix domain-independent bugs in an existing code where there was a misunderstanding regarding the usage of an API (debug-corrective). We classified questions available on Stack Overflow by the main concerns of askers, and we used those classified as how-to-do-it and debug-corrective to analyze the coverage of API elements on the discussions related to such questions. Our cases included the well-known and popular Swing and Android APIs. Our main findings showed that the crowd provides more content for debug-corrective tasks than for how-to-do-it tasks, regardless of the API. Android API elements are more discussed by the crowd compared to Swing. Moreover, we observed that some API elements are frequently mentioned together in discussions, and that there is a strong association between API coverage on Stack Overflow and its usage in real software systems. Crowd documentation may not be a complete substitute for official documentation because of its partial coverage, especially for how-to-do-it tasks. However, it can still significantly enhance the existent documentation, especially for the most commonly used API elements, providing code samples and explanations on a large variety of usage nuances. Finally, taking advantage of the high coverage for debug-corrective tasks, a new kind of debugging assistant may be conceived.

EXAF: A search engine for sample applications of object-oriented framework-provided concepts

Context: Object-oriented application frameworks, such as Java Swing, provide reusable code and design for implementing domain-specific concepts, such as Context Menu, in software applications. Hence, use of such frameworks not only can decrease the time and the cost of developing new software applications, but also can increase their maintainability. However, the main problems of using object-oriented application frameworks are their large and complex APIs, and often incomplete user manuals. To mitigate these problems, developers often try to learn how to implement their desired concepts from available sample applications. Nonetheless, this introduces another hard and time-consuming challenge which is finding proper sample applications.Objective: To address this difficulty, we introduce EXAF (EXample Applications Finder) that helps developers find sample applications which implement their desired framework-provided concepts.Method: The majority of existing framework comprehension approaches can only help programmers to get familiar with the usage of particular fine-grained API elements of the desired framework such as its classes and methods. Nevertheless, our approach is able to find sample applications that implement a particular framework-provided concept. To this end, EXAF benefits from the Latent Semantic Indexing (LSI) information retrieval technique. We evaluated the approach using 24 concepts on top of the Microsoft .Net, Qt, and Java Swing frameworks.Results: Based on our evaluations, the precision of EXAF is more than 79%. Besides, it can find some sample applications that could not be found by common code search engines such as the ones which are used in SourceForge and Google Code.Conclusions: The results of our evaluations indicate that EXAF is effective in practice, and yields better search results because it considers various artifacts of a project like user reviews and bug reports.

Recommending reference API documentation

Reference documentation is an important source of information on API usage. However, information useful to programmers can be buried in irrelevant text, or attached to a non-intuitive API element, making it difficult to discover. We propose to detect and recommend fragments of API documentation potentially important to a programmer who has already decided to use a certain API element. We categorize text fragments in API documentation based on whether they contain information that is indispensable, valuable, or neither. From the fragments that contain knowledge worthy of recommendation, we extract word patterns, and use these patterns to automatically find new fragments that contain similar knowledge in unseen documentation. We implemented our technique in a tool, Krec, that supports both information filtering and discovery. In an evaluation study with randomly-sampled method definitions from ten open source systems, we found that with a training set derived from about 1000 documentation units, we could issue recommendations with 90 % precision and 69 % recall. In a study involving ten independent assessors, indispensable knowledge items recommended for API types were judged useful 57 % of the time and potentially useful an additional 30 % of the time.

Characterisation of a functional E box motif in the proximal rat preprotachykinin-A promoter

Three E box motifs, which are upstream of the major transcriptional start site, have previously been characterised in the rat preprotachykinin-A (rPPT) promoter. Only one of these, in the proximal promoter spanning nucleotides −67 to −47, has been demonstrated to support reporter gene expression in clonal cell lines under basal growth conditions. Here we demonstrate that the reporter gene expression can be further induced by the action of phorbol 12-myristate 13-acetate (TPA) and nerve growth factor (NGF), respectively, in both HeLa and the neuronally derived PC12 cells. This response is due to the E box motif and not an overlapping consensus sequence for a putative API element, a class of element previously demonstrated to respond to both TPA and NGF in these cell lines. Finally, we demonstrate that this E box motif can support similar levels of reporter gene expression in primary cultures of dorsal root ganglion neurons as observed in clonal cell lines, demonstrating that E box binding complexes can (1) function as a transcriptional regulator in dorsal root ganglion neurons and (2) bind to and therefore presumably regulate rPPT promoter activity.