@conference {apiace:2024:icwe, title = {How Many Web APIs Evolve Following Semantic Versioning?}, booktitle = {24th International Conference on Web Engineering (ICWE)}, year = {2024}, month = {June}, address = {Tampere, Finland}, keywords = {API Analytics, API Evolution, Semantic Versioning, Web API}, author = {Souhaila Serbout and Cesare Pautasso} } @conference {apiace:2023:icwe, title = {An empirical study of Web API versioning practices}, booktitle = {23rd International Conference on Web Engineering (ICWE)}, year = {2023}, month = {June}, publisher = {Springer}, organization = {Springer}, address = {Alicante, Spain}, abstract = {As Web APIs evolve, developers assign them version identifiers to reflect the amount and the nature of changes that the API clients should expect. In this work we focus on identifying versioning practices adopted by Web API developers by extracting and classifying version identifiers found in a large collection of OpenAPI descriptions. In particular, we observe how frequently different versioning schemes have been adopted for identifying both stable and preview releases (e.g., simple version counters, semantic versioning, or release timestamps). We further study the stability of versioning schemes during APIs evolution. We also detect APIs which offer dynamic access to versioning metadata through dedicated endpoints as well as APIs which support clients expecting to reach up to 14 different versions of the same API at the same time. Overall the results offer a detailed view over current Web API versioning practices and can serve as the basis for future discussions on how to standardize critical API versioning metadata.}, keywords = {API Analytics, Versioning}, author = {Souhaila Serbout and Cesare Pautasso} } @conference {apiace:2022:icws, title = {How Composable is the Web? An Empirical Study on OpenAPI Data model Compatibility}, booktitle = {IEEE World Congress on Services (ICWS Symposium on Services for Machine Learning)}, year = {2022}, month = {July}, publisher = {IEEE}, organization = {IEEE}, address = {Barcelona, Spain}, abstract = {Composing Web APIs is a widely adopted practice by developers to speed up the development process of complex Web applications, mashups, and data processing pipelines. However, since most publicly available APIs are built independently of each other, developers often need to invest their efforts in solving incompatibility issues by writing ad-hoc glue code, adapters and message translation mappings. How likely are Web APIs to be directly composable? The paper presents an empirical study to determine the potential composability of a large collection of 20,587 public Web APIs by verifying their schemas{\textquoteright} compatibility. We define three levels of data model elements compatibility -- considering matches between property names and/or data types -- which can be determined statically based on API descriptions conforming to the OpenAPI specification. The study research questions address: to which extent are Web APIs compatible; the average number of compatible endpoints within each API; the likelihood of finding two APIs with at least one pair of compatible endpoints. To perform the analysis we developed a compatibility checker tool which can statically determine API schema compatibility on the three levels and find matching pairs of API responses which can be directly forwarded as requests to the same or other APIs. We run the tool on a dataset of 751,390 request and response message schemas extracted from publicly available OpenAPI descriptions. The results indicate a relatively high number of compatible APIs when matching their data models only on the level of their elements{\textquoteright} data type. However, this number gets lower narrowing the scope to only the ones handling data objects having identical properties name. The average likelihood of finding two compatible APIs with both matching property names and data types reaches 21\%. Also, the number of compatible endpoints within the same API is very low.}, keywords = {API Analytics, empirical study, mashups, OpenAPI, Web APIs}, author = {Souhaila Serbout and Cesare Pautasso and Uwe Zdun} } @conference {2022:sose:apiace, title = {Impact of API Rate Limit on Reliability of Microservices- Based Architectures}, booktitle = {16th International Conference on Service-Oriented System Engineering (SOSE 2022)}, year = {2022}, month = {August}, publisher = {IEEE}, organization = {IEEE}, address = {San Francisco, USA}, abstract = {Many API patterns and best practices have been developed around microservices-based architectures, such as Rate Limiting and Circuit Breaking, to increase quality properties such as reliability, availability, scalability, and performance. Even though estimates on such properties would be beneficial, especially during the early design of such architectures, the real impact of the patterns on these properties has not been rigorously studied yet. This paper focuses on API Rate Limit and its impact on reliability properties from the perspective of API clients. We present an analytical model that considers specific workload configurations and predefined rate limits and then accurately predicts the success and failure rates of the back-end services. The model also presents a method for adaptively fine-tuning rate limits. We performed two extensive data experiments to validate the model and measured Rate Limiting impacts, firstly on a private cloud to minimize latency and other biases, and secondly on the Google Cloud Platform to test our model in a realistic cloud environment. In both experiments, we observed a low percentage of prediction errors. Thus, we conclude that our model can provide distributed system engineers and architects with insights into an acceptable value for the rate limits to choose for a given workload. Very few works empirically studied the impact of Rate Limit or similar API-related patterns on reliability.}, keywords = {API Analytics}, author = {Amine El Malki and Uwe Zdun and Cesare Pautasso} } @conference {apiace:2022:ecsa, title = {To deprecate or to simply drop operations? An empirical study on the evolution of a large OpenAPI collection}, booktitle = {16th European Conference on Software Architecture (ECSA)}, volume = {13444}, year = {2022}, month = {September}, pages = {38-46}, publisher = {Springer}, organization = {Springer}, address = {Prague, Czech Republic}, keywords = {API Analytics, API Evolution}, doi = {doi.org/10.1007/978-3-031-16697-6_3}, author = {Fabio Di Lauro and Souhaila Serbout and Cesare Pautasso} } @conference {2022:icsa, title = {Web APIs Structures and Data Models Analysis}, booktitle = {19th IEEE International Conference on Software Architecture (ICSA 2022)}, year = {2022}, month = {March}, publisher = {IEEE}, organization = {IEEE}, address = {Honululu, Hawaii}, abstract = {Microservice architectures emphasize keeping components small, to foster autonomy, low coupling, and independent evolution. In this large-scale empirical study, we measure the size of Web API specifications mined from open source repositories. These APIs are modeled using the OpenAPI Specification (OAS), which, in addition to documenting the offered operations, also contain schemas definitions for the data exchanged with the API request and response message payloads. This study has as a goal to build empirical knowledge about: (1) How big and diverse are real-world web APIs both in terms of their operations and data, (2) How different API structures use and reuse schema definitions. By mining public software repositories on Github, we gathered 42,194 valid OAS specifications published between 2014-2021. }, keywords = {API Analytics, API Size, OpenAPI}, author = {Souhaila Serbout and Fabio Di Lauro and Cesare Pautasso} }