A Conceptual Framework for API Refactoring in Enterprise Application Architectures

TL;DR

The paper addresses how to implement API refactorings in evolving enterprise service architectures by introducing EMI, a framework that evaluates refactorings along two axes: generality and distribution. EMI defines six development strategies and scores them on efficiency ($E$), maintainability ($M$), and isolation ($I$) using a $1$–$3$ scale, acknowledging that no single strategy is perfect ($9$ max). Validation is performed by applying the framework to Jolie-based refactorings, including the API Key pattern and non-behavioral patterns like Merge Endpoints and Version Identifier, and demonstrating how language features can reduce friction in refactoring. The work provides canonical recipes to realize specific EMI scores, enabling developers to systematically reason about and implement API refactorings in practice with implications for architecture evolution in enterprise applications.

Abstract

Enterprise applications are often built as service-oriented architectures, where the individual services are designed to perform specific functions and interact with each other by means of well-defined APIs (Application Programming Interfaces). The architecture of an enterprise application evolves over time, in order to adapt to changing business requirements. This evolution might require changes to the APIs offered by services, which can be achieved through appropriate API refactorings. Previous studies on API refactoring focused on the effects on API definitions, with general considerations on related forces and smells. So far, instead, the development strategy for realising these refactorings has received little attention. This paper addresses exactly this aspect. We introduce a conceptual framework for the implementation of API refactorings. Our framework elicits that there are important trade-offs and choices, which significantly affect the efficiency, maintainability, and isolation properties of the resulting architecture. We validate our framework by implementing several refactorings that introduce established API patterns with different choices, which illustrates the guiding principles offered by our framework. Our work also elicits, for the first time, how certain programming language features can reduce friction in applying API refactoring and open up more architectural choices.

Figures (1)

• Figure 1: Possible choices for distribution.