Automated API Property Inference Techniques

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.

Software reuse through Application Programming Interfaces (APIs) is an integral part of software development. The functionality offered by an API is not always accessed uniformly throughout the lifetime of a client program. We propose Temporal API Usage Pattern Mining to detect API usage patterns in terms of their time of introduction into client programs. We detect concepts as distinct groups of API functionality from the change history of a client program. We locate those concepts in the client change history and detect temporal usage patterns, where a pattern contains a set of concepts that were added into the client program in a specific temporal order. We investigated the properties of temporal API usage patterns through a multiple-case study of three APIs and their use in up to 19 client software projects. Our technique was able to detect a number of valuable patterns in two out of three of the APIs investigated. Further investigation showed some patterns to be relatively consistent between clients, produced by multiple developers, and not trivially derivable from program structure or API documentation.

Context: From the past few years, Application Programming Interface (API) is widely used for mobile- and web-based application developments. Software developers can integrate third-party services into their projects to achieve their development goals efficiently using APIs; however, with the rapid increase in the number of APIs, the manual selection of Mashup-oriented API is becoming more difficult for the developer. Objective: In the COVID-19 pandemic, everyone wants an update about the latest Standard Operating Procedures (SOPs) and the latest information on COVID-19. Additionally, a software developer wants to develop an application that provides the SOPs and latest information of COVID-19; a developer can add these functionalities into an application using COVID-19-based APIs. Moreover, the current work aims at proposing a COVID-19-based API recommendation system for the developers. Method: In this study, we propose a COVID-19-based API recommendation system for developers. The recommendation system takes a developer query as input and recommends top-3 APIs and supported features, which help the developer during software development. Furthermore, the proposed COVID-19-based API recommendation system ensures the maximum participation of the developers by validating the recommended APIs and recommendation system from the expert developers using research questionnaires. Results: Additionally, the proposed COVID-19-based API recommendation system’s output is validated by expert developers and evaluated on 120 expert developers’ queries. In addition, experiment results show that single value decomposition achieves better prediction. Conclusion: We conclude that it is significantly important to recommend APIs along with supported features to the developer for project development, and future work is needed to take more developer’s queries also to build Integrated Development Environment for the developers.

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.

PurposeThis 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/approachIn 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.FindingsThe 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/implicationsThis 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 implicationsThis 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/valueAPI 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 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.

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.

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.

Application Programming Interfaces (APIs) could greatly facilitate the exchange of data and functionalities between software applications in a flexible, controlled and secure way, especially on the web. Private companies, from startups to enterprises, have been using APIs for several years now, but it is only recently that APIs have seen increased interest in the public sector. API adoption in the public sector faces organisational, technical, legal and economic obstacles, and to overcome these barriers, proposed methods from the private sector and early adopters in the public sector provide a way forward. The available documentation is often sparse, difficult to find and to reuse for new contexts. No past efforts to collect and analyse these resources have been made. To address this shortcoming, this paper describes a landscape analysis in four areas: the main European Commission policy instruments on the adoption of APIs, the available web API standards, a set of European government API strategies and cases, and a list of government proposed methods distilled from more than 3900 documents. Our results reveal that European policy legislation and associated instruments promote, and in some cases mandate, the use of APIs, and that governments’ API strategies in the European Union are rather young but also that there are well known web APIs standards and proposed methods ready to support the digital transformation of governments through rapid, harmonised and successful adoption of APIs.

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.

This article consists of a collection of slides from the author's PowerPoint conference presentation. The paper argues that the diversity of services and networks, demands a fresh approach to service creation. The authors argue that the Application Programming Interface (API) approach promises to meet many of the demands of service creation in the new environment. Formalising at the level of the API in service creation allows the underlying control structures the flexibility to be ahnost completely proprietary in nature. However it will be argued that the API approach demands new additional structures to make the model commercially viable. This paper examines the requirements of the API server and introduces the notion of an API state-machine. An API server allows third party software providers or end users access to control resources without regard to how the offered services are to be implemented. It must therefore provide the flexibility of service creation with the restriction placed by policing functions to protect against misuse of code or malicious intent The server must also provide access to support infrastructures such as billing systems and management systems. In addition it also needs to be capable of fme grained process control. Hence, the aims of the state machine are complex. The paper describes work being done at UCL in defining a state machine, similar in many respects to that of the Basic Call State Model and the Call Party Handling model but for the API server case. The state machine aims to mask the service on offer from the external requests. It also aims to reduce the interfaces between service providers to a simple state machine view that seeks to eliminates problems such as deadlock or integrity violations between complex multiple service provider interactions. The paper also examines the relationship between API approaches and the TINA framework. It argues that TINA evolution can be pushed forward by an intermediate API stage in development

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.

Recent industrial and academic research has focused on data-driven analytics with smartphones by collecting user interaction, context, and device systems data through Application Programming Interfaces (APIs) and sensors. The Android operating system provides various APIs to collect such mobile usage and sensor data for third-party developers. Usage Statistics API (US API) and Accessibility Service API (AS API) are representative Android APIs for collecting app usage data and are used for various research purposes, as they can collect fine-grained interaction data (e.g., app usage history and user interaction type). Furthermore, other sensor APIs help to collect a user’s context and device state data, along with AS/US APIs. This review investigates mobile usage and sensor data-driven research using AS/US APIs by categorizing the research purposes and the data types. In this article, the surveyed studies are classified as follows: five themes and 21 subthemes and a four-layer hierarchical data classification structure. This allows us to identify a data usage trend and derive insight into data collection according to research purposes. Several limitations and future research directions of mobile usage and sensor data-driven analytics research are discussed, including the impact of changes in the Android API versions on research, the privacy and data quality issues, and the mitigation of reproducibility risks with standardized data typology.

API (Application Programming Interface) documentation often only describes individual APIs and lacks information on complex API relations and code examples. Retrieval-based and generation-based methods can both produce documentation that includes API relationship descriptions and code examples. However, they are limited by the richness of available API resources. As a result, they struggle to be effective when dealing with resource-scarce languages such as Kotlin. We propose an on-demand API tutorial generation method for resource-scarce languages, transferring API knowledge from a resource-rich language like Java to Kotlin using an AI chain. Evaluating our method on 500 Kotlin APIs, we generated more API documents than the state-of-the-art retrieval-based method ADECK and the generate-based method gDoc. The number of API guidelines generated by our method is 37 times that of ADECK and 1.6 times that of gDoc. Compared with the scheme that did not adopt the knowledge transfer strategy, the success rate of our method has increased by 31.25 percentage points. This demonstrates the feasibility and potential of using LLMs to create new API knowledge across languages.

Providing access to observational climate data and its metadata has been important for climatology. Historically, climate data has been made available by some national data platforms or through the European Climate Assessment and Database (ECA&D). Users often had to pay for data access and output was provided in different formats. The newly in force EU open Data Directive 2019/1024 requires National Meteorological and Hydrological Services (NMHSs) to make their High Value Datasets, including meteorological datasets, available through machine readable application programming interfaces (APIs). RODEO work package 5 (WP5) aims to unite ten NMHSs that are developing APIs for their climate databases. Afterwards, an API aggregator service unifies the individual APIs, so that the clients can use all APIs with only one request.  In this presentation we will report on progress made in RODEO WP5.   WP5 worked on uniforming climate datasets, including its metadata. A group of experts decided on the choice of variable to include, granularity of daily and hourly observations, and preferred controlled vocabularies. Metadata guidance from WMO, Copernicus and ESIP are incorporated to adhere to the FAIR principles.  The API recommendations for NMHS data providers will follow the Environmental Data Retrieval (EDR) API specification. Using an EDR API it is possible to perform geospatial and temporal filterable queries of climate data. The EDR specification, published by Open Geospatial Consortium (OGC) in 2016, has, over recent years, gained traction as an ideal method to distribute meteorological data over the internet.   The OGC has adopted CoverageJSON as data format standard alongside the EDR API. This format will be the preferred output format for an NMHS climate data API.  The EDR aggregator service will facilitate the unification of individual NMHS APIs to one central EDR API. The aggregator service can add caching, output format conversion from CoverageJSON to NetCDF or CSV and support queries across collections.  To aid in the development of NMHS climate data EDR APIs, a workshop “Build an EDR API in a day” is being prepared to run in June 2024. A spin-off of this event is being planned in Spring 2025 for non-RODEO partners.