Street Computing: Towards an Integrated Open Data Application Programming Interface (API) for Cities

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.

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. 

Code examples are important resources for expressing correct application programming interface (API) usages. However, many framework and library APIs fail in offering sufficient code examples in corresponding API documentations. This is because constructing proper code examples for documentation purpose takes significant developers' efforts. To reduce such effort, this work proposes a methodology, PropER-Doc, that recommends proper code examples for documentation purpose. PropER-Doc accepts queries from API developers and utilizes code search engines (CSEs) to collect corresponding code example candidates. The structural and conceptual links between API elements are captured from the API implementation and available API documents to guide candidate recommendation. During recommendation, PropER-Doc groups collected candidates based on involved API types for distinguishing different API usages. To assist API developers in selecting proper candidates, a diagrammatic presentation and three code example appropriateness metrics are also developed in {PropER-Doc}. Two case studies on Eclipse JDT framework are conducted to confirm the effectiveness of PropER-Doc.

ABSTRACTWhile many firms in recent years have started to offer public Application Programming Interfaces (APIs), firms struggle with shaping digital platform strategies that align API design with aspired business goals and the demands of external developers. We address the lack of theory that explains the performance impacts of three API archetypes (professional, mediation, and open asset services). We couple survey data from 152 API product managers with manually coded API design classifications. With this data, we conduct cluster and regression analyses that reveal moderating effects of two value creation strategies (economies of scope in production and innovation) on the relationships between API archetype similarity and two API performance outcomes: return on investment and diffusion. We contribute to IS literature by developing a unifying theory that consolidates different theoretical perspectives on API design, by extending current knowledge on the performance effects of API design, and by empirically studying the distinct circumstances under which digital platforms facilitate economies of scope in production or in innovation. Our results provide practical implications on how API providers can align API archetype choice with the value creation strategy and the API’s business objective.

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.