API Design Research Articles

The API Performance Contract

When you call functions in an API, you expect them to work correctly; sometimes this expectation is called a contract between the caller and the implementation. Callers also have performance expectations about these functions, and often the success of a software system depends on the API meeting these expectations. So there’s a performance contract as well as a correctness contract. The performance contract is usually implicit, often vague, and sometimes breached (by caller or implementation). How can this aspect of API design and documentation be improved?

Simplicity‐first model‐based plug‐in development

SUMMARYIn this article, we present our experience with over a decade of strict simplicity orientation in the development and evolution of plug‐ins. The point of our approach is to enable our graphical modeling framework jABC to capture plug‐in development in a domain‐specific setting. The typically quite tedious and technical plug‐in development is shifted this way from a programming task to the modeling level, where it can be mastered also by application experts without programming expertise. We show how the classical plug‐in development profits from a systematic domain‐specific API design and how the level of abstraction achieved this way can be further enhanced by defining adequate building blocks for high‐level plug‐in modeling. As the resulting plug‐in models can be compiled and deployed automatically, our approach decomposes plug‐in development into three phases where only the realization phase requires plug‐in‐specific effort. By using our modeling framework jABC, this effort boils down to graphical, tool‐supported process modeling. Furthermore, we support the automatic completion of process sketches for executability. All this will be illustrated along the most recent plug‐in‐based evolution of the jABC framework, which witnessed quite some bootstrapping effects. Copyright © 2013 John Wiley & Sons, Ltd.

The latency, accuracy, and battery (LAB) abstraction

Emerging mobile applications that sense context are poised to delight and entertain us with timely news and events, health tracking, and social connections. Unfortunately, sensing algorithms quickly drain the phone's battery. Developers can overcome battery drain by carefully optimizing context sensing but that makes programming with context arduous and ties applications to current sensing hardware. These types of applications embody a twist on the classic tension between programmer productivity and performance due to their combination of requirements. This paper identifies the latency, accuracy, battery (LAB) abstraction to resolve this tension. We implement and evaluate LAB in a system called Senergy. Developers specify their LAB requirements independent of inference algorithms and sensors. Senergy delivers energy efficient context while meeting the requirements and adapts as hardware changes. We demonstrate LAB's expressiveness by using it to implement 22 context sensing algorithms for four types of context (location, driving, walking, and stationary) and six diverse applications. To demonstrate LAB's energy optimizations, we show often an order of magnitude improvements in energy efficiency on applications compared to prior approaches. This relatively simple, priority based API, may serve as a blueprint for future API design in an increasingly complex design space that must tradeoff latency, accuracy, and efficiency to meet application needs and attain portability across evolving, sensor-rich, heterogeneous, and power constrained hardware.

Making the Mobile Web Faster

Mobile clients have been on the rise and will only continue to grow. This means that if you are serving clients over the Internet, you cannot ignore the customer experience on a mobile device. There are many informative articles on mobile performance, and just as many on general API design, but you’ll find few discussing the design considerations needed to optimize the back-end systems for mobile clients. Whether you have an app, mobile Web site, or both, it is likely that these clients are consuming APIs from your back-end systems. Certainly, optimizing the on-mobile performance of the application is critical, but software engineers can do a lot to ensure that mobile clients are remotely served both data and application resources reliably and efficiently.

GReTL: an extensible, operational, graph-based transformation language

This article introduces the graph-based transformation language GReTL. GReTL is operational, and transformations are either specified in plain Java using the GReTL API or in a simple domain-specific language. GReTL follows the conception of incrementally constructing the target metamodel together with the target graph. When creating a new metamodel element, a set-based semantic expression is specified that describes the set of instances that have to be created in the target graph. This expression is defined as a query on the source graph. GReTL is a kernel language consisting of a minimal set of operations, but it is designed for being extensible. Custom higher-level operations can be built on top of the kernel operations easily. After a description of the foundations of GReTL, its most important elements are introduced along with a transformation example in the field of metamodel integration. Insights into the design of the GReTL API are given, and a convenience copy operation is implemented to demonstrate GReTL's extensibility.

Comparing complexity of API designs

Embedded, textual DSLs are often provided as an API wrapped around object-oriented application frameworks to ease framework integration. While literature presents claims that DSL-based application development is beneficial, empirical evidence for this is rare. We present the results of an experiment comparing the complexity of three different object-oriented framework APIs and an embedded, textual DSL. For this comparative experiment, we implemented the same, non-trivial application scenario using these four different APIs. Then, we performed an Object-Points (OP) analysis, yielding indicators for the API complexity specific to each API variant. The main observation for our experiment is that the embedded, textual DSL incurs the smallest API complexity. Although the results are exploratory, as well as limited to the given application scenario and a single embedded DSL, our findings can direct future empirical work. The experiment design is applicable for similar API design evaluations.

API design for C++ by Martin Reddy

API design for C++ by Martin Reddy

Specification and Standardization of a Java Trusted Computing API

SUMMARYThe paradigm of Trusted Computing promises a new approach to improve the security of computer systems. The core functionality, based on a hardware component known as Trusted Platform Module, is integrated into commodity hardware. However, operating system integration and application software support remains limited at present. In particular, for Java, the most widely used platform‐independent computing environment, there is currently no generally accepted Trusted Computing API. In this article, we describe the design of a high‐level API for Trusted Computing. We report on the current state of the Trusted Computing Group's software architecture and on previous approaches targeting Java. We derive our requirements and design goals and describe a novel API design. We report on our transparent approach to standardization in the Java Community Process. The result of this effort is the API we propose in the Java Specification Request 321. In this work, we not only present the design of this new API but also discuss implementation and testing strategies. Copyright © 2011 John Wiley & Sons, Ltd.

Optimization Design of Beam Pumping Unit Based on Response Surface Method

An optimization design method is developed for the beam pumping unit, which is based on the API-RP-11L design criteria. The Response Surface Method is used to calculate the structural reliability of the beam pumping unit. The optimization design method not only provides an efficient and fast optimization tool for the modular design of the beam pumping unit, but also offers an integral design calculation in accordance with the API design code. The function and theory of this optimization design method are given by this paper, as well as some concrete calculation examples.

Design of a safety-critical geocast API for vehicular coordination

With the development of autonomous driving systems and vehicular networks, vehicles will gain the possibility of taking driving decisions and coordinating them with each other. A suitable communication primitive for this type of application is geocast. Unfortunately, current geocast techniques do not address the reliability problems that arise in what is a safety-critical application domain. Communication failures are difficult to detect, not only due to an unreliable communication channel, but also particularly due to the changing presence of vehicles in the target area. Dealing with these challenges requires an integrated approach, exploiting communication, sensing and driving rules. In this paper, we present the API of a safety-critical geocast service that allows the sender of a message to reliably confirm reception through feedback and spatial membership. We specify the service based on the requirements of the application domain and the limitations of the environment.

Benchmarking library and application software with Data Envelopment Analysis

Library software is generally believed to be well-structured and follows certain design guidelines due to the need of continuous evolution and stability of the respective APIs. We perform an empirical study to investigate whether the design of open-source library software is actually superior to that of application software. By analyzing certain design principles and heuristics that are considered important for API design, we extract a set of software metrics that are expected to reflect the improved nature of libraries. An initial comparison by conventional statistical analysis confirms the overall belief that products of different software size scale should not be compared by simply examining metric values in isolation. In this paper, we propose the use of Data Envelopment Analysis (DEA), borrowed from production economics, as a means of measuring and benchmarking the quality of different object-oriented software designs captured by software metrics and apply this approach to the comparison of library and application software. The advantages offered by DEA and the differences between the application of DEA in an economic and a technological context are discussed. Results of the approach are presented for 44 open-source projects, equally divided between libraries and applications.

API design matters

Bad application programming interfaces plague software engineering. How do we get things right?

Reducing threats from flawed security APIs: The banking PIN case

Despite best efforts from security API designers, flaws are often found in widely deployed security APIs. Even APIs with a formal proof of security may not guarantee absolute security when used in a real-world device or application. In parallel to spending research efforts to improve security of these APIs, we argue that it may be worthwhile to explore design criteria that would reduce the impact of an API exploit, assuming flaws cannot completely be removed from security APIs. We use such a design philosophy in dealing with PIN cracking attacks on financial PIN processing APIs; several of these attacks have been reported in the last few years, e.g., Berkman and Ostrovsky (FC 2007), Bond (CHES 2001). Our solution is called salted-PIN: a randomly generated salt value of adequate length (e.g., 128 bits) is stored on a bank card in plaintext, and in an encrypted form at a verification facility under a bank-chosen salt key. Instead of sending the regular user PIN, salted-PIN requires an ATM to generate a Transport Final PIN from a user PIN, account number, and the salt value (stored on the bank card) through, e.g., a pseudo-random function. We explore different attacks on this solution, and propose variants of salted-PIN that can protect against known attacks. Depending on the solution variation, attacks at a malicious intermediate switch now may only reveal the Transport Final PIN; both the user PIN and salt value remain beyond the reach of an attacker's switch. Salted-PIN requires modifications to service points (e.g., ATM, point-of-sale), issuer/verification facilities, and bank cards; however, changes to intermediate switches are not required.

Enforcing object protocols by combining static and runtime analysis

In this paper, we consider object protocols that constrain interactions between objects in a program. Several such protocols have been proposed in the literature. For many APIs (such as JDOM, JDBC), API designers constrain how API clients interact with API objects. In practice, API clients violate such constraints, as evidenced by postings in discussion forums for these APIs. Thus, it is important that API designers specify constraints using appropriate object protocols and enforce them. The goal of an object protocol is expressed as a protocol invariant. Fundamental properties such as ownership can be expressed as protocol invariants. We present a language, PROLANG, to specify object protocols along with their protocol invariants, and a tool, INVCOP++, to check if a program satisfies a protocol invariant. INVCOP++ separates the problem of checking if a protocol satisfies its protocol invariant (called protocol correctness), from the problem of checking if a program conforms to a protocol (called program conformance). The former is solved using static analysis, and the latter using runtime analysis. Due to this separation (1) errors made in protocol design are detected at a higher level of abstraction, independent of the program's source code, and (2) performance of conformance checking is improved as protocol correctness has been verified statically. We present theoretical guarantees about the way we combine static and runtime analysis, and empirical evidence that our tool INVCOP++ finds usage errors in widely used APIs. We also show that statically checking protocol correctness greatly optimizes the overhead of checking program conformance, thus enabling API clients to test whether their programs use the API as intended by the API designer.

Review: Practical API Design: Confessions of a Java Framework Architect (1st edition) Jaroslav Tulach, Apress, 2008, $74.99, ISBN: 9781430209737

Review: Practical API Design: Confessions of a Java Framework Architect (1st edition) Jaroslav Tulach, Apress, 2008, $74.99, ISBN: 9781430209737

IDL compiler API design, application and validation based on XML API

In order to adapt different languages and platforms, the paper discusses how to process and validate IDL symbol table and intermediate code by XML API. It puts emphasis on IDL API extension towards DOM API based on the idea of combining XML with IDL compilers. At last, the IDL compiler designing framework based on XML API is given, in which compiler front end can be managed and validated by some XML techniques and tools, IDL API can be validated on the basis of test, so IDL intermediate code is provided with maintainability, portability and generation. IDL compiler can be developed and extended by XML-based API, which realizes versatility and portability of modern compiler.

API: Design Matters

After more than 25 years as a software engineer, I still find myself underestimating the time it will take to complete a particular programming task. Sometimes, the resulting schedule slip is caused by my own shortcomings: as I dig into a problem, I simply discover that it is a lot harder than I initially thought, so the problem takes longer to solve—such is life as a programmer. Just as often I know exactly what I want to achieve and how to achieve it, but it still takes far longer than anticipated. When that happens, it is usually because I am struggling with an API that seems to do its level best to throw rocks in my path and make my life difficult. What I find telling is that, after 25 years of progress in software engineering, this still happens. Worse, recent APIs implemented in modern programming languages make the same mistakes as their two-decade-old counterparts written in C. There seems to be something elusive about API design that, despite many years of progress, we have yet to master.

Extending Security Protocol Analysis: New Challenges

We argue that formal analysis tools for security protocols are not achieving their full potential, and give only limited aid to designers of more complex modern protocols, protocols in constrained environments, and security APIs. We believe that typical assumptions such as perfect encryption can and must be relaxed, while other threats, including the partial leakage of information, must be considered if formal tools are to continue to be useful and gain widespread, real world utilisation. Using simple example protocols, we illustrate a number of attacks that are vital to avoid in security API design, but that have yet to be modelled using a formal analysis tool. We seek to extract the basic ideas behind these attacks and package them into a wish list of functionality for future research and tool development.

Inside java 2 platform security: architecture, API design and implementation [Book Review

Inside java 2 platform security: architecture, API design and implementation [Book Review

Stiffened steel plates under uniaxial compression

The stability of steel plates stiffened with tee-shape sections under uniaxial compression and combined uniaxial compression and bending was investigated using a finite element model. The emphasis of the work presented in this paper was to find the parameters that uniquely describe the strength and behaviour of stiffened steel plates. A finite element model, validated using the results of tests on full-size stiffened plate panels, was used to investigate the scale effect for five dimensionless parameters. The parameters investigated were: the transverse slenderness of the plate, the slenderness of the web and flange of the stiffener, the ratio of torsional slenderness of the stiffener to the transverse slenderness of the plate, and the stiffener-to-plate area ratio. Average magnitude residual stresses and initial imperfections were assumed for this study. A parametric study covering a wide range of dimensionless parameters indicated that stiffened steel plates do not fail by stiffener tripping unless a bending moment is applied to create flexural compressive stresses in the stiffener. Although plate buckling and overall buckling were found to lead to a very stable post-buckling behaviour, the interaction between these two buckling modes was found to give rise to a sudden loss of capacity following initial plate buckling. The plate transverse slenderness, the stiffener slenderness-to-plate slenderness ratio, and the stiffener-to-plate area ratio were found to have a significant effect on this behaviour. A comparison of the numerical analysis results with API and DnV design guidelines indicates that the guidelines predict stiffened steel plate capacity with various degrees of success, depending on the governing mode of failure. Neither guidelines address the potential interaction-buckling phenomenon.