On implementing a high-performance open API with Java

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.

This paper aims to analyze the current context of Application Programming Interface (API) technology, with focus in External API (Public API or Open API) by news organizations. The adoption of API has been considered a technological strategy that introduces innovation processes in media groups. This technological approach allows the public access to data, increase the distribution of journalistic information and transparency which improves the credibility of organizations. However, there is not a pattern strategic in the use of API adopted by news organizations and the external developers have used various technologies, named toolkit, to store, process, analyze and visualize data. The study cases were The New York Times, The Guardian, NPR and, ESPN.

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.

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.

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.

Public Windows Interface (PWI) is an effort by several computer industry leaders to ensure that the Microsoft Windows application programming interface (API) moves into the world of open systems. By formalizing the existing API as a standard, PWI will provide a snapshot to which developers can refer and upon which they can build their applications. By making PWI an open standard, all parties will have an equal opportunity to compete and to propose future changes. PWI supporters have encouraged Microsoft to submit its complete API to a neutral standards body and to agree to abide by changes and extensions approved by that body. So far, Microsoft has declined to do so. Certain of the technology companies who see the value of creating a formal standard have committed resources to the laborious task of fully and formally documenting the API. These companies will submit the resulting specification to the appropriate neutral standards body upon its completion, where it will be available for all to use at no cost. With PWI as a new standard, users will be able to choose among multiple implementations, leverage their prior investments, and use familiar applications on a host of new devices. Independent software vendors will benefit from a more stable, open API, and will be able to funnel their resources into new development. Systems vendors will broaden the range of applications available for their platforms. In short, PWI will bring the benefits of open systems to the PC world. >

CORDITE: The Curated CORona Drug InTERactions Database for SARS-CoV-2

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.

The aim of this system is to use open source APIs to invoke and process the results of the Web services and to apply confidentiality and integration to the result of the Web services. In this system Web Services are requested using URL (Uniform Resource Locator) query to the WWW instead of SOAP message. When invoking the web services using JAX-RPC (Java Api for Xml-Based Remote Procedure Call) with SOAP request, the result returned may not be received properly due to de-serialization problem of complex XML data sets. Therefore it is required to invoke such services by submitting the query as URL query and received the results as XML data set. This XML data set may be hampered by man-in-middle attack during transfer. Hence this system uses open source APIs for providing XML signature and XML encryption. At the receiver after decryption and integrity check, the required node from XML data set is extracted and presented to the user. This article is focused on usage of open source APIs (Application program interface) for invoking web services as Restful Web services, applying XML signature and XML encryption, parsing the XML result after reverse process at receiver side and extracting the required nodes according to the user given condition. The problem of de-serialization in receiving huge XML result is resolved in the proposed system.

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.