An Experimental Performance Evaluation of Cloud-API-Based Applications

At present, accessing and processing Earth Observation (EO) data on different cloud platforms requires users to exercise distinct communication strategies as each backend platform is designed differently. The openEO API (Application Programming Interface) standardises EO-related contracts between local clients (R, Python, and JavaScript) and cloud service providers regarding data access and processing, simplifying their direct comparability. Independent of the providers’ data storage system, the API mimics the functionalities of a virtual EO raster data cube. This article introduces the communication strategy and aspects of the data cube model applied by the openEO API. Two test cases show the potential and current limitations of processing similar workflows on different cloud platforms and a comparison of the result of a locally running workflow and its openEO-dependent cloud equivalent. The outcomes demonstrate the flexibility of the openEO API in enabling complex scientific analysis of EO data collections on cloud platforms in a homogenised way.

Following the Service-Oriented Architecture, Cloud services are exposed as Web APIs (Application Program Interface), which serve as the contracts between the service providers and service consumers. With increasing massive and broad applications of Cloud-based development, a large number of diversified APIs are emerging. Due to their wide impacts, any flaw in the cloud APIs may lead to serious consequences. API testing is thus necessary to ensure the availability, reliability, and stability of cloud services. The research proposed an approach to automating API testing following the model-driven architecture, so that services can be continuously fetched, analyzed and validated. A prototype system ATcloud was constructed to illustrate the process of API understanding, test scenario modeling using directed graph annotated with transfer probabilities between operations, cloud-based test resources management, distributed workload simulation, and performance monitoring.

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.

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.

The rapid digitalization of higher education institutions (HEIs) has accelerated adoption of interoperable systems, cloud platforms, and data-driven services. As universities migrate toward hybrid ecosystems composed of legacy applications, SaaS platforms, learning management systems (LMS), student information systems (SIS), and ID management tools, the need for a unified, secure, and scalable integration strategy becomes paramount. Application Programming Interfaces (APIs) have emerged as the primary enabler of seamless interoperability; however, their deployment introduces substantial cybersecurity, governance, privacy, and architectural challenges. This paper presents a comprehensive blueprint for building a secure API-driven enterprise specifically tailored to the operational and regulatory realities of higher education institutions. Through an examination of evolving integration paradigms, threat vectors, identity frameworks, governance models, and architectural patterns, this work provides a reference architecture for institutions transitioning toward API-first ecosystems. Higher education environments differ significantly from traditional enterprises. They operate under open-access cultures, support thousands of users with heterogeneous privileges, and manage sensitive academic, personal, research, and financial data. Key challenges include decentralization, autonomous departments, inconsistent data models, lack of centralized governance, fragmented integrations, deficient access controls, and widespread usage of shadow IT.

Cloud computing has led to dramatic growth in the volume, variety, and velocity of cancer data. However, cloud platforms and services present new challenges for cancer research, particularly in understanding the practical tradeoffs between cloud performance, cost, and complexity. The goal of this study was to describe the practical challenges when using a cloud-based service to improve the cancer clinical trial matching process. We collected information for all interventional cancer clinical trials from ClinicalTrials.gov and used the Google Cloud Healthcare Natural Language Application Programming Interface (API) to analyze clinical trial Title and Eligibility Criteria text. An informatics pipeline leveraging interoperability standards summarized the distribution of cancer clinical trials, genes, laboratory tests, and medications extracted from cloud-based entity analysis. There were a total of 38,851 cancer-related clinical trials found in this study, with the distribution of cancer categories extracted from Title text significantly different than in ClinicalTrials.gov (P < .001). Cloud-based entity analysis of clinical trial criteria identified a total of 949 genes, 1,782 laboratory tests, 2,086 medications, and 4,902 National Cancer Institute Thesaurus terms, with estimated detection accuracies ranging from 12.8% to 89.9%. A total of 77,702 API calls processed an estimated 167,179 text records, which took a total of 1,979 processing-minutes (33.0 processing-hours), or approximately 1.5 seconds per API call. Current general-purpose cloud health care tools-like the Google service in this study-should not be used for automated clinical trial matching unless they can perform effective extraction and classification of the clinical, genetic, and medication concepts central to precision oncology research. A strong understanding of the practical aspects of cloud computing will help researchers effectively navigate the vast data ecosystems in cancer research.

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.