Temporal analysis of API usage concepts

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

Application Programming Interfaces (APIs) are everyday tools for every software professional. When creating an API, a designer typically abstracts the tasks the API intends to perform. The API user, on the other hand, should use the API to perform specific-propose tasks. During the development of an API, the designer needs to write dialogues with which the user will interact with the API, performing a conversation between them. In this way, an API capable of offering effective dialogues to its users is called a conversational API. A conversational API is the one that is capable of communicating to its users its form of use and its internal logic of operation, making it clear the design decisions when abstracting concepts and tasks. In this paper, we present Colloquy, an evidence-based method to support the design of conversational APIs. Colloquy was conceived based on the lessons learned from an action research we conducted to identify effective strategies for designing conversational APIs. For six months, we followed the redesign of an existing API developed at an R&D laboratory of a large IT company. In this paper, we also present the first empirical evaluation of Colloquy. We conducted a case study in which the method was employed to design an API for refactoring source code in the Java programming language. Among other benefits, we found that Colloquy was effective in developing empathy with users and modeling conversations with them. Besides, Colloquy contributed to identifying new requirements and created models as API documentation.

While Application Programming Interface (API) enables an easy and flexible software development process, selecting a best-fit API is often non-straightforward in practice due to misunderstanding on the API specification or a complex programming context etc.. Consequently, the API selection has always been time-consuming and error-prone. In recent years, API recommendation systems have been introduced to help developers choose an API automatically, e.g., Eclipse and IntelliJ can generate an internal or user-defined API on the fly. Other research leveraged language models to capture the regularity in API usage and further guide the completion of APIs. While existing approaches provided a general support for API usage, they suffer from the lack of semantic awareness (e.g., Eclipse) and code relevance (e.g., language model based methods). To overcome these limitations, we proposed Crmac in this paper. The key insight of Crmac is a combination of a cache language model which learns code regularity from both open-source projects and local projects, as well as a relevance mining engine that identifies similar code to enable a weighted language model training. In our empirical evaluation, Crmac overwhelmed n-gram approaches, with an improvement of 5.28% in terms of top 10 accuracy. Moreover, over 79% APIs were correctly predicted in the top 10 guesses of Crmac.

APIs (application programming interfaces) play a key role in software development. Virtually, all programmers are potential users of third-party APIs. From the perspective of the theory of Semiotic Engineering, we may characterize an API as an artifact mediating the communication between two types of developers: the API designers and its users. During the construction of an API, the designers should establish proper dialogues with the users. These dialogues will enable the conversation of these actors at the interaction time. In this way, we define a conversational API as an API capable of offering effective dialogues to its users. In this paper, we introduce Colloquy, a method for supporting the design of conversational APIs. Colloquy results from the lessons learnt during an action research conducted for redesigning a real and complex API. The set of Colloquy resources allow API designers to go beyond conventional concerns with usability. We also report in this paper a case study in which Colloquy was used for redesigning a refactoring API. The study findings indicate the method helped the designer creating empathy with the API users, as well as better reflecting and depicting the requirements and the conversations that the API should attend to the different user profiles.

Learning to use a software framework and its API (Application Programming Interfaces) can be a major endeavor for novices. To help, we have built a critic to advise the use of an API based on the formal semantics of the API. Specifically, the critic offers advice when the symbolic state of the API client code triggers any API usage rules. To assess to what extent our critic can help solve practical API usage problems and what kinds of API usage rules can be formulated, we manually analyzed 150 discussion threads from the Java Swing forum. We categorize the discussion threads according to how they can be helped by the critic. We find that API problems of the same nature appear repeatedly in the forum, and that API problems of the same nature can be addressed by implementing a new API usage rule for the critic. We characterize the set of discovered API usage rules as a whole. Unlike past empirical studies that focus on answering why frameworks and APIs are hard to learn, ours is the first designed to produce systematic data that have been directly used to build an API support tool.

Application Programming Interfaces (APIs) are a way to reuse existing functionalities of one application in another one. However, due to lacking knowledge on the correct usage of a particular API, developers sometimes commit misuses, causing unintended or faulty behavior. To detect and eventually repair such misuses automatically, inferring API usage patterns from real-world code is the state-of-the-art. A contradiction to an identified usage pattern denotes a misuse, while applying the pattern fixes the respective misuse. The success of this process heavily depends on the quality of the usage patterns and on the code from which these are inferred. Thus, a lack of code demonstrating the correct usage makes it impossible to detect and fix a misuse. In this paper, we discuss the potential of using machine-learning vector embeddings to improve automatic program repair and to extend it towards cross-API and cross-language repair. We illustrate our ideas using one particular technique for API-embedding (i.e., API2Vec) and describe the arising possibilities and challenges.

In modern software engineering, API (Application Programming Interface) is widely used to develop applications rapidly by reusing data structure, frameworks, class libs, and etc. However, due to the considerable number of interfaces, lack of documents and timely maintenance and updates, APIs are often used in a wrong way. Therefore, it has become an important problem to detect API misuse in an automatic way. Many existing automatic API detecting methods do not make full use of APIs’ potential semantic information and independent integrity of each API. In this paper, we employ Stacked LSTM to learn the API usage specification to detect the API misuse defects. Specifically, first, we obtain ACSG (API Call Syntax Graph) through the static analysis of source code. And then, based on ACSG, we generate API sequences, and transform the sequences into for training. Third, in order to represent the APIs in a semantic way, we apply word2vec as a pre-training model to embed features of each API. Though the stacked LSTM model, we regard embedding precious API sequence as the input to model the API use specifications and discover the potential API misuse defects by judging whether the next API is in the output (API probability list) or not. We design experiments to evaluate the effectiveness our method with Java Cryptography APIs and their used code, and the results show the advancement of our proposed method.

Application Programming Interfaces (API) are exposed to developers in order to reuse software libraries. API directives are natural-language statements in API documentation that make developers aware of constraints and guidelines related to the usage of an API. This paper presents the design and the results of an empirical study on the directives of API documentation of object-oriented libraries. Its main contribution is to propose and extensively discuss a taxonomy of 23 kinds of API directives.

To facilitate the integration of terminologies into applications, various terminology services application programming interfaces (API) have been developed in the recent past. In this study, three publicly available terminology services API, RxNav, UMLSKS and LexBIG, are compared and functionally evaluated with respect to the retrieval of information from one biomedical terminology, RxNorm, to which all three services provide access. A list of queries is established covering a wide spectrum of terminology services functionalities such as finding RxNorm concepts by their name, or navigating different types of relationships. Test data were generated from the RxNorm dataset to evaluate the implementation of the functionalities in the three API. The results revealed issues with various aspects of the API implementation (eg, handling of obsolete terms by LexBIG) and documentation (eg, navigational paths used in RxNav) that were subsequently addressed by the development teams of the three API investigated. Knowledge about such discrepancies helps inform the choice of an API for a given use case.

External service integration and adherence to industry standards has become ever more important for collections data management platforms. External APIs (Application Programming Interfaces), allow for the development of bi-directional data flows critical to service integration. In contrast to service-oriented backend APIs, public APIs must have continually up-to-date, comprehensive documentation that covers common use cases, on-the-fly request validation, and meaningful error messages. OpenAPI (OpenAPI Initiative 2021), a machine-readable API documentation specification can help significantly with testing and maintenance, and libraries can be used to automate common maintenance tasks. Specify 7 is a biological collections data management platform developed by the Specify Collections Consortium (Specify Software Consortium 2021). This presentation summarizes the challenges and lessons learned with publishing the existing backend Specify 7 API to a public-facing external API. Each Specify 7 API is composed of 200 resources. A standard set of CRUD (Create, Read, Update, Delete) operations is provided for each resource for client interaction with a group of service-based endpoints for bulk operations such as file uploads, file-based data imports, and attachment manipulation. To support the migration, we developed a custom library to enhance request validation. Parameter validation is extended through a real-time comparison against the existing schema and data. The library is available to the community under a MIT license on GitHub (https://github.com/specify/open_api_tools/). In this presentation, we will close with an overview of the next steps for the Specify 7 public API. These include: An update to the latest OpenAPI specification, version 3.1. The latest version aims to increase compatibility with the Javascript Object Notation (JSON) Schema specification, and thus would allow us to use JSON Schema (IETF Trust 2021) validation frameworks. An in-depth evaluation of GraphQL for its ability to force all endpoints to be strongly typed and automatic validation of request parameters and response objects. An update to the latest OpenAPI specification, version 3.1. The latest version aims to increase compatibility with the Javascript Object Notation (JSON) Schema specification, and thus would allow us to use JSON Schema (IETF Trust 2021) validation frameworks. An in-depth evaluation of GraphQL for its ability to force all endpoints to be strongly typed and automatic validation of request parameters and response objects.

Application Programming Interfaces (APIs) have emerged as critical infrastructure components in modern digital services, yet traditional Web Application Firewalls (WAFs) prove inadequate against sophisticated attacks targeting business logic flaws and access control vulnerabilities. Behavioral threat detection platforms address these gaps by establishing baseline patterns of legitimate API usage and identifying deviations that signal potential threats such as credential stuffing, data scraping, and unauthorized data exfiltration. These systems leverage machine learning algorithms to analyze API traffic in real-time, generating contextual alerts that distinguish between benign anomalies and genuine security incidents. Advanced capabilities include automated discovery of undocumented or shadow APIs, classification of sensitive data flows, and implementation of tokenization strategies to protect information in transit. Integration with Security Information and Event Management (SIEM) systems enables orchestrated incident response, while continuous posture assessment ensures ongoing compliance with security policies. This comprehensive framework transforms API security from reactive rule-based filtering to proactive behavioral monitoring, significantly reducing the attack surface and enabling organizations to detect and respond to threats that would otherwise bypass conventional security controls.

It has been always a challenge to grade and assess the students’ CAD (Computer-Aided Design) three-dimensional models in the class. The high number of the files and complexity of models make the task time-consuming and tedious many times. For example, even opening and closing each CAD file takes a lot of time. When hundreds of CAD models need to open and verified, it takes more than one hour to finish the task. The work has been done to simplify this task and make it easy using Commercial CAD software’s API (Application Programming Interface), which can be used to automate and customize the CAD software. The API contains hundreds of functions that you can call from Visual Basic for Applications (VBA), VB.NET, Visual C#, Visual C++ 6.0, and Visual C++/CLI. These functions provide direct access to CAD functionality such as opening a file, check the important physical properties of three-dimensional models. Custom API program has been programmed for the task. The custom program executes the internal commends in CAD software and retrieve the data you need from each CAD file automatically. The program opens the multiple CAD files in the folder and check each file’s physical properties and save the information in MS Excel for the review. The program checks the volume (w.r.t the given coordinates) in two standard units (English and S.I. Units), the creator of model (to prevent the plagiarism) and degrees of sketch. In this paper, the following topics will be discussed and presented. 1) The problem with manual grading and assessment, 2) History and background of API functionality in commercial CAD software, 3) Examples of simple source code for API usage, 4) Running example of the API program for the given task, 5) Comparison between manual assessment and automatic assessment using API in terms of spent time. 6) Future improvement with API program. Actual demonstration of the program will be given during the presentation.

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.

Frameworks and libraries offer reusable and customizable functionality through Application Programming Interfaces (APIs). Correctly using large and sophisticated APIs can represent a challenge due to hidden assumptions and requirements. Numerous approaches have been developed to infer properties of APIs, intended to guide their use by developers. With each approach come new definitions of API properties, new techniques for inferring these properties, and new ways to assess their correctness and usefulness. This paper provides a comprehensive survey of over a decade of research on automated property inference for APIs. Our survey provides a synthesis of this complex technical field along different dimensions of analysis: properties inferred, mining techniques, and empirical results. In particular, we derive a classification and organization of over 60 techniques into five different categories based on the type of API property inferred: unordered usage patterns, sequential usage patterns, behavioral specifications, migration mappings, and general information.

There are several acoustic monitoring software packages that allow for the creation and execution of algorithms that automate detection, classification, and localization (DCL). Algorithms written for one program are generally not portable to other programs, and usually must be written in a specific programming language. We have developed an application programming interface (API) that seeks to resolve these issues by providing a plugin framework for creating algorithms for two acoustic monitoring packages: Ishmael and PAMGuard. This API will allow new detection, classification, and localization algorithms to be written for these programs without requiring knowledge of the monitoring software’s source code or inner workings, and lets a single implementation run on either platform. The API also allows users to write DCL algorithms in a wide variety of languages. We hope that this will promote the sharing and reuse of algorithm code. [Funding from ONR.]