Design Of Application Programming Interface Research Articles

A Unified Framework for Manipulating N-dimensional Astronomical Data and Coordinate Transformations in Python: The NDCube 2 and Astropy APE-14 World Coordinate System APIs

The NDCube 2 API is a Python application programming interface (API) for storing and manipulating N-dimensional coordinate-aware astronomical data. While there are Python packages for handling astronomical data and coordinate transformations separately and for handling specific combinations of dimensions and transformations, none provide a unified and agnostic way of handling them simultaneously. This leads to a proliferation of different APIs for conducting the same analysis tasks on similar types of observations and introduces technical barriers between multi-instrument studies and cross-community collaboration. In this paper, we outline how the NDCube 2 API and its implementation in the open-source, community-developed ndcube package, together with the AstroPy WCS API, help to solve this problem. We discuss the guiding principles underpinning the API design and provide examples of how it is already being used to serve broad sections of the astronomy community, including agency-funded missions. The aim of this paper is to help users better understand the purpose and potential of the NDCube 2 API and ndcube package and hence how to more effectively deploy them in scientific analyses and software development.

Setting Sustainability Goals for Biodiversity Informatics Infrastructure

Biodiversity data are of crucial importance in the implementation of sustainable development strategies (UN Sustainable Development Goals, EU Taxonomy for Sustainable Activities), because they contribute to deepening our understanding of marine and terrestrial ecosystems and our assessment of the impact of human activities on the planet. Yet, biodiversity informatics itself is lacking an overall sustainability plan that addresses “the three E’s of environment, equity, and economics” (Brinkmann 2021) in relation to biodiversity data, their lifecycle, and related technologies. This is especially problematic given that data-driven biodiversity research has had a ten-fold increase (GBIF Secretariat 2022). This implies higher costs for data management, storage and transmission, a larger carbon footprint, and open issues about data access and reuse. SMART (Specific, Measurable, Assignable, Realistic, Time-Related) goals can help to set a sustainability strategy for biodiversity informatics because they bring together the ambitions of an organisation with the action plan necessary to realise these ambitions. When G.T. Doran proposed the use of SMART goals (Doran 1981), his aim was not to create a checklist, but a tool to get results and produce deliverables, which is precisely what is required for implementing an effective sustainability strategy. Three examples are provided here to explain the value of a SMART approach to set sustainability goals in biodiversity informatics. Goal 1, Increase energy efficiency of computing hardware: A large part of the energy consumption in data centres is due to hardware operations. Several strategies can be pursued to increase energy efficiency in this area, such as activity optimisation for Graphic Processing Units (GPUs), improvements in the effectiveness of cooling systems, and replacement of Central Processing Units (CPUs) with more efficient GPUs. This sustainability goal is specific because it clearly identifies what needs to be achieved; it is measurable because pre- and post- energy consumption are known and can be easily compared with the expected improvement; it is assignable because data centre managers can be identified as the agents of change; it is realistic because there are multiple technological solutions to achieve the goal; and time-related because a roadmap for change stretching through months or years can be set up. Achieving this goal is evidently beneficial for both the budget and the carbon footprint of biodiversity informatics, as higher energy efficiency is associated to lower running costs and also contributes to reduce greenhouse gases emissions. Goal 2, Reducing data storage costs per terabyte: Data storage is becoming one of the most significant operating expenses in data-driven organisations due to the considerable increase in the amount of data produced. It is therefore imperative to reduce costs by selecting appropriate storage options (on-premises or cloud services), by adopting compressed formats whenever possible, and by avoiding data redundancy. This goal is SMART because it sets a target (the expected cost reduction can be quantified) and establishes measures (cost per terabyte) to assess its achievement. It can be assigned to data managers, who can choose among different technologies and service providers to lower costs, and can be scheduled over time according to budget needs. The achievement of this goal has clear economic benefits, but also increases the social sustainability of biodiversity informatics, because it makes data-driven research affordable even for organisations with limited financial means. Goal 3, Decreasing API (Application Programming Interface) response time and bandwidth for data transmission: Data sharing is a key activity in biodiversity informatics and APIs have become the standard technology for achieving it. Improving API performance is therefore crucial to enhance the user experience for stakeholders interested in biodiversity data. In particular, API response time and bandwidth required for data transmission control whether users will be able to access immediately and download satisfactorily the data they are interested in. Goal 3 is SMART because API response time and bandwidth are known measures and can be improved using strategies such as caching and concurrency to handle data requests more rapidly and delivering data in compressed formats to reduce bandwidth. Software developers and project managers involved in API design and maintenance are the people in charge of this goal. They decide the best strategy and timeline to pursue changes. Improving API performance increases the social sustainability of biodiversity informatics because it promotes uncomplicated data access for all stakeholders interested in biodiversity data. It also lowers energy consumption for downloading data benefitting the environment.

SLR: From Saltzer and Schroeder to 2021…47 Years of Research on the Development and Validation of Security API Recommendations

Producing secure software is challenging. The poor usability of security Application Programming Interfaces (APIs) makes this even harder. Many recommendations have been proposed to support developers by improving the usability of cryptography libraries—rooted in wider best practice guidance in software engineering and API design. In this SLR, we systematize knowledge regarding these recommendations. We identify and analyze 65 papers, offering 883 recommendations. Through thematic analysis, we identify seven core ways to improve usability of APIs. Most of the recommendations focus on helping API developers to construct and structure their code and make it more usable and easier for programmers to understand . There is less focus, however, on documentation , writing requirements , code quality assessment , and the impact of organizational software development practices . By tracing and analyzing paper ancestry, we map how this knowledge becomes validated and translated over time. We find that very few API usability recommendations are empirically validated, and that recommendations specific to usable security APIs lag even further behind.

Libkrylov: A modular open-source software library for extremely large on-the-fly matrix computations.

We present the design and implementation of libkrylov, an open-source library for solving matrix-free eigenvalue, linear, and shifted linear equations using Krylov subspace methods. The primary objectives of libkrylov are flexible API design and modular structure, which enables integration with specialized matrix-vector evaluation "engines." Libkrylov features pluggable preconditioning, orthonormalization, and tunable convergence control. Diagonal (conjugate gradient, CG), Davidson, and Jacobi-Davidson preconditioners are available, along with orthonormal and nonorthonormal (nKs) schemes. All functionality of libkrylov is exposed via Fortran and C application programming interfaces (APIs). We illustrate the performance of libkrylov for eigenvalue calculations arising in time-dependent density functional theory (TDDFT) in the Tamm-Dancoff approximation (TDA) and discuss the convergence behavior as a function of preconditioning and orthonormalization methods.

Assessing the linguistic quality of REST APIs for IoT applications

Internet of Things (IoT) is a growing technology that relies on connected ‘things’ that gather data from peer devices and send data to servers via APIs (Application Programming Interfaces). The design quality of those APIs has a direct impact on their understandability and reusability. This study focuses on the linguistic design quality of REST APIs for IoT applications and assesses their linguistic quality by performing the detection of linguistic patterns and antipatterns in REST APIs for IoT applications. Linguistic antipatterns are considered poor practices in the naming, documentation, and choice of identifiers. In contrast, linguistic patterns represent best practices to APIs design. The linguistic patterns and their corresponding antipatterns are hence contrasting pairs. We propose the SARAv2 (Semantic Analysis of REST APIs version two) approach to perform syntactic and semantic analyses of REST APIs for IoT applications. Based on the SARAv2 approach, we develop the REST-Ling tool and empirically validate the detection results of nine linguistic antipatterns. We analyse 19 REST APIs for IoT applications. Our detection results show that the linguistic antipatterns are prevalent and the REST-Ling tool can detect linguistic patterns and antipatterns in REST APIs for IoT applications with an average accuracy of over 80%. Moreover, the tool performs the detection of linguistic antipatterns on average in the order of seconds, i.e., 8.396 s. We found that APIs generally follow good linguistic practices, although the prevalence of poor practices exists.

Multimedia Conferencing at the Network Edge

The fifth generation (5G) mobile system provides enhanced data rates, ultra-low latency, and better network resource usage for Internet of Things (IoT) devices in a dense environment. The integration of 5G IoT and multimedia conferencing enables collaboration between humans and devices by launching new capabilities. In this paper, an approach to define Application Programming Interfaces (API) for multimedia conference control is presented. The API design follows the principles of Multi-access Edge Computing (MEC) and features the inherent advantages of MEC. The API is described by resource structure, data types, and sequence diagrams that illustrate the API functionality. Some implementation issues are discussed, and the injected latency is evaluated.

An interview with Joanna Suau from Infobip on the design of application programming interface (API) documentation

Abstract About Joanna Suau Joanna studied English literature and culture at the University of Silesia in Poland, where she was born. She did a technical writing postgraduate degree in the picturesque city of Krakow and moved to the U.K. in 2012, to work for shipping solutions provider Pierbridge, where she mainly focused on user guides and walkthroughs of various types of shipping applications. Interested in what makes an app tick, Joanna started learning programming language (JavaScript) and explored CSS and HTML in more detail. This is when she discovered her passion for writing clean and appealing developer-oriented documentation, and moved to the start-up company Moltin, to become a part of the Developer Success team. Joanna has changed industry, and currently works in the field of telecommunication. She works for a messaging services provider, Infobip, contributing content to their robust API solutions.

CoolBox: a flexible toolkit for visual analysis of genomics data

BackgroundData visualization, especially the genome track plots, is crucial for genomics researchers to discover patterns in large-scale sequencing dataset. Although existing tools works well for producing a normal view of the input data, they are not convenient when users want to create customized data representations. Such gap between the visualization and data processing, prevents the users to uncover more hidden structure of the dataset.ResultsWe developed CoolBox—an open-source toolkit for visual analysis of genomics data. This user-friendly toolkit is highly compatible with the Python ecosystem and customizable with a well-designed user interface. It can be used in various visualization situations like a Swiss army knife. For example, to produce high-quality genome track plots or fetch commonly used genomic data files with a Python script or command line, to explore genomic data interactively within Jupyter environment or web browser. Moreover, owing to the highly extensible Application Programming Interface design, users can customize their own tracks without difficulty, which greatly facilitate analytical, comparative genomic data visualization tasks.ConclusionsCoolBox allows users to produce high-quality visualization plots and explore their data in a flexible, programmable and user-friendly way.

Does TDWG Need an API Design Guideline?

RESTful APIs (REpresentational State Transfer Application Programming Interfaces) are the most commonly used mechanism for biodiversity informatics databases to provide open access to their content. In its simplest form an API provides an interface based on the HTTP protocol whereby any client can perform an action on a data resource identified by a URL using an HTTP verb (GET, POST, PUT, DELETE) to specify the intended action. For example, a GET request to a particular URL (informally called an endpoint) will return data to the client, typically in JSON format, which the client converts to the format it needs. A client can either be custom written software or commonly used programs for data analysis such as R (programming language), Microsoft Excel (everybody’s favorite data management tool), OpenRefine, or business intelligence software. APIs are therefore a valuable mechanism for making biodiversity data FAIR (findable, accessible, interoperable, reusable). There is currently no standard specifying how RESTful APIs should be designed, resulting in a variety of URL and response data formats for different APIs. This presents a challenge for API users who are not technically proficient or familiar with programming if they have to work with many different and inconsistent data sources. We undertook a brief review of eight existing APIs that provide data about taxa to assess consistency and the extent to which the Darwin Core standard (Wieczorek et al. 2021) for data exchange is applied. We assessed each API based on aspects of URL construction and the format of the response data (Fig. 1). While only cursory and limited in scope, our survey suggests that consistency across APIs is low. For example, some APIs use nouns for their endpoints (e.g. ‘taxon’ or ‘species’), emphasising their content, whereas others use verbs (e.g. ‘search’), emphasising their functionality. Response data seldom use Darwin Core terms (two out of eight examples) and a wide range of terms can be used to represent the same concept (e.g. six different terms are used for dwc:scientificNameAuthorship). Terms that can be considered metadata for a response, such as pagination details, also vary considerably. Interestingly, the public interfaces for the majority of APIs assessed do not provide POST, PUT or DELETE endpoints that modify the database. POST is only used for providing more detailed request bodies to retrieve data than possible with GET. This indicates the primary use of APIs by biodiversity informatics platforms for data sharing. An API design guideline is a document that provides a set of rules or recommendations for how APIs should be designed in order to improve their consistency and useability. API design guidelines are typically created by particular organizations to standardize API development within the organization, or as a guideline for programmers using an organization’s software to build APIs (e.g., Microsoft and Google). The API Stylebook is an online resource that provides access to a wide range of existing design guidelines, and there is an abundance of other resources available online. This presentation will cover some of the general concepts of API design, demonstrate some examples of how existing APIs vary, and discuss potential options to encourage standardization. We hope our analysis, the available body of knowledge on API design, and the collective experience of the biodiversity informatics community working with APIs may help answer the question “Does TDWG need an API design guideline?”

A systematic gray literature review: The technologies and concerns of microservice application programming interfaces

AbstractThe microservice application programming interface (API) becomes a growing concern in the IT industry, as a result of the increasing usage of microservice architecture style. There exist many successful practices among companies, communities, and so on. In contrast, the related academic research is still at an early stage, where lacks an overview of technologies for the design, implementation and operation of microservice APIs, as well as a general picture of concerns. In this article, we try to fill this gap by eliciting the technologies and concerns on microservice APIs and establishing a microservice API description model, with the intention of aiding researchers to gain an overview of this field and find possible research directions, and helping practitioners to better understand microservice APIs and be aware of the existing approaches for daily work. Twelve academic papers and 38 gray literatures are selected and analyzed following the systematic literature review approach. Besides, we give our observations from this study. For researchers, our findings show the most cared concerns of practitioners, and our description model can be used as a reference for new theories, experiments, and future research dimensions. For practitioners, our study can be used as a guideline for microservices experimentation and a starting point for practice.

Путеводитель по проектированию удобных Web-API

Cloud computing trends such as Software as a Service (SaaS) enable providers to host complex applications over the Internet, making them available to external consumers through an Application Programming Interface (API). The success of a SaaS, and in some sense any distributed system, is greatly influenced by its API. Highly usable APIs improve the efficiency of the development process and its quality, ensuring that programmers continue to appreciate other aspects of the API while increasing their productivity. Different studies state that the design phase within the development process of an API is the most appropriate to address usability issues. Therefore, usability should be considered as an explicit criterion in the design of an API. In this paper, we propose a design guide for web APIs with an emphasis on usability, using the best practices of usable web APIs design. Our design guide is based on an adaptation of the design science research methodology (DSRM), and it is complemented with a systematic literature review and gray literature analysis concerning methods, techniques, and tools used to develop usable APIs.

A Design Guide for Usable Web APIs

Cloud computing trends such as Software as a Service (SaaS) enable providers to host complex applications over the Internet, making them available to external consumers through an Application Programming Interface (API). The success of a SaaS, and in some sense any distributed system, is greatly influenced by its API. Highly usable APIs improve the efficiency of the development process and its quality, ensuring that programmers continue to appreciate other aspects of the API while increasing their productivity. Different studies state that the design phase within the development process of an API is the most appropriate to address usability issues. Therefore, usability should be considered as an explicit criterion in the design of an API. In this paper, we propose a design guide for web APIs with an emphasis on usability, using the best practices of usable web APIs design. Our design guide is based on an adaptation of the design science research methodology (DSRM), and it is complemented with a systematic literature review and gray literature analysis concerning methods, techniques, and tools used to develop usable APIs.

Fostering Value Creation with Digital Platforms: A Unified Theory of the Application Programming Interface Design

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.

Software Components and Product Variety in a Digital Platform Ecosystem: A Dynamic Network Analysis of WordPress

Outside developers invert the firm in a platform ecosystem. A platform ecosystem creates value for its users through the work of outside developers who develop a variety of products within the ecosystem. These outside developers use software components, e.g., Application Programming Interfaces (APIs) provided by the platform owner (internal APIs) as well as digital service providers (external APIs) to generate a variety of products for the ecosystem. However, the impact of external APIs on product variety within an ecosystem has not been fully explored. To fill the gap, we use a network method to model how different types and use frequencies of APIs affect an increase in functional categories of products developed by outside developers, which in turn collectively represent product variety. Drawing on a combinatorial design perspective, we specify that product variety is increased through the re-combination of different API types provided by the platform owner and digital service providers. Based on the core/periphery model of programming resources, we find that according to their use frequency and relative importance there are three layers of API, i.e., complete core, regular core, and periphery, in a digital platform ecosystem. We conduct an empirical study using the longitudinal data of all available plug-in source codes from WordPress.org, the world's largest content management platform ecosystem. By analyzing WordPress' plug-ins over the ten-year period since its inception, we discovered that the re-combination of APIs from these three distinct layers display different effects on product variety. We further find the new insight that the combinatorial design of external APIs affects the increase of product variety, but such effect can be weakened in categories mainly consisting of a dominant design.

CAPS: a supervised technique for classifying Stack Overflow posts concerning API issues

The design and maintenance of APIs (Application Programming Interfaces) are complex tasks due to the constantly changing requirements of their users. Despite the efforts of their designers, APIs may suffer from a number of issues (such as incomplete or erroneous documentation, poor performance, and backward incompatibility). To maintain a healthy client base, API designers must learn these issues to fix them. Question answering sites, such as Stack Overflow (SO), have become a popular place for discussing API issues. These posts about API issues are invaluable to API designers, not only because they can help to learn more about the problem but also because they can facilitate learning the requirements of API users. However, the unstructured nature of posts and the abundance of non-issue posts make the task of detecting SO posts concerning API issues difficult and challenging. In this paper, we first develop a supervised learning approach using a Conditional Random Field (CRF), a statistical modeling method, to identify API issue-related sentences. We use the above information together with different features collected from posts, the experience of users, readability metrics and centrality measures of collaboration network to build a technique, called CAPS, that can classify SO posts concerning API issues. In total, we consider 34 features along eight different dimensions. Evaluation of CAPS using carefully curated SO posts on three popular API types reveals that the technique outperforms all three baseline approaches we consider in this study. We then conduct studies to find important features and also evaluate the performance of the CRF-based technique for classifying issue sentences. Comparison with two other baseline approaches shows that the technique has high potential. We also test the generalizability of CAPS results, evaluate the effectiveness of different classifiers, and identify the impact of different feature sets.

A Survey of Asynchronous Programming Using Coroutines in the Internet of Things and Embedded Systems

Many Internet of Things and embedded projects are event driven, and therefore require asynchronous and concurrent programming. Current proposals for C++20 suggest that coroutines will have native language support. It is timely to survey the current use of coroutines in embedded systems development. This article investigates existing research which uses or describes coroutines on resource-constrained platforms. The existing research is analysed with regard to: software platform, hardware platform, and capacity; use cases and intended benefits; and the application programming interface design used for coroutines. A systematic mapping study was performed, to select studies published between 2007 and 2018 which contained original research into the application of coroutines on resource-constrained platforms. An initial set of 566 candidate papers, collated from on-line databases, were reduced to only 35 after filters were applied, revealing the following taxonomy. The C 8 C++ programming languages were used by 22 studies out of 35. As regards hardware, 16 studies used 8- or 16-bit processors while 13 used 32-bit processors. The four most common use cases were concurrency (17 papers), network communication (15), sensor readings (9), and data flow (7). The leading intended benefits were code style and simplicity (12 papers), scheduling (9), and efficiency (8). A wide variety of techniques have been used to implement coroutines, including native macros, additional tool chain steps, new language features, and non-portable assembly language. We conclude that there is widespread demand for coroutines on resource-constrained devices. Our findings suggest that there is significant demand for a formalised, stable, well-supported implementation of coroutines in C++, designed with consideration of the special needs of resource-constrained devices, and further that such an implementation would bring benefits specific to such devices.

API practices and paradigms: Exploring the protocological parameters of APIs as key facilitators of sociotechnical forms of exchange

The use of application programming interfaces (APIs) to develop and design technological forms of structured exchanges is an increasingly prevalent practice at present, allowing data to be shared, automated, circulated and redistributed in wider computational culture. Despite acting as key infrastructural elements and connectors, the prominence and importance of APIs is still under recognised. Via a brief survey of the history of API development and then closer regulatory and technical analysis of the long standing, non-profit net.art generator (nag) (1997), this study aims to bring to the fore key sociotechnical elements of API design. Particular attention is given to protocological forms of control as these can be enacted through APIs via the regulations, terms of service and specific operational processes and affordances of fetching networked data. net.art generator uses the Google API and URL and specific attention is given to Google’s setting of terms for exchange. In doing so, we give a few suggestions for how anyone working with APIs might think through certain key questions around the creation and use of APIs, particularly in regards to the parameters of openness, accessibility and terms of inclusivity that APIs set upon practices of knowing, sharing, participation and exchange.

Weaving seams with data: Conceptualizing City APIs as elements of infrastructures

This article addresses the role of application programming interfaces (APIs) for integrating data sources in the context of smart cities and communities. On top of the built infrastructures in cities, application programming interfaces allow to weave new kinds of seams from static and dynamic data sources into the urban fabric. Contributing to debates about “urban informatics” and the governance of urban information infrastructures, this article provides a technically informed and critically grounded approach to evaluating APIs as crucial but often overlooked elements within these infrastructures. The conceptualization of what we term City APIs is informed by three perspectives: In the first part, we review established criticisms of proprietary social media APIs and their crucial function in current web architectures. In the second part, we discuss how the design process of APIs defines conventions of data exchanges that also reflect negotiations between API producers and API consumers about affordances and mental models of the underlying computer systems involved. In the third part, we present recent urban data innovation initiatives, especially CitySDK and OrganiCity, to underline the centrality of API design and governance for new kinds of civic and commercial services developed within and for cities. By bridging the fields of criticism, design, and implementation, we argue that City APIs as elements of infrastructures reveal how urban renewal processes become crucial sites of socio-political contestation between data science, technological development, urban management, and civic participation.

Creating Web APIs with Python and Flask

Learn how to set up a basic Application Programming Interface (API) to make your data more accessible to users. This lesson also discusses principles of API design and the benefits of APIs for digital projects.

RESTful APIs for the 5G ServiceBased Architecture

5G sets out to be the global connectivity and integration platform for a broad variety of industries in the upcoming decade. In order to do so it not only needs to fulfil the requirements of these industries but must also ensure its tight integration into the digital infrastructure of the 2020s by embracing key technologies. This article shows how one of these key technologies, the RESTful design of Application Programming Interfaces (APIs), is used in the 5G Service Based Architecture (SBA). The basic principles of modern API development are explained and it is shown how those integrate into the specific needs of the 5G Core Network.