@conference {apiace:2023:europlop, title = {API Rate Limit Adoption - A Pattern Collection}, booktitle = {28th European Conference on Pattern Languages of Programs (EuroPLoP 2023)}, year = {2023}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Kloster Irsee, Germany}, keywords = {API Design Patterns}, doi = {10.1145/3628034.3628039}, url = {https://dl.acm.org/doi/10.1145/3628034.3628039}, author = {Souhaila Serbout and Amine El Malki and Cesare Pautasso and Uwe Zdun} } @book {2023:map, title = {Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges}, series = {Addison-Wesley Signature Series (Vernon)}, year = {2023}, pages = {544}, publisher = {Pearson Education}, organization = {Pearson Education}, abstract = {Proven Patterns for Designing Evolvable High-Quality APIs--For Any Domain, Technology, or Platform APIs enable breakthrough innovation and digital transformation in organizations and ecosystems of all kinds. To create user-friendly, reliable and well-performing APIs, architects, designers, and developers need expert design guidance. This practical guide cuts through the complexity of API conversations and their message contents, introducing comprehensive guidelines and heuristics for designing APIs sustainably and specifying them clearly, for whatever technologies or platforms you use. In Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges, five expert architects and developers cover the entire API lifecycle, from launching projects and establishing goals through defining requirements, elaborating designs, planning evolution, and creating useful documentation. They crystallize the collective knowledge of many practitioners into 44 API design patterns, consistently explained with context, pros and cons, conceptual solutions, and concrete examples. To make their pattern language accessible, they present a domain model, a running case study, decision narratives with pattern selection options and criteria, and walkthroughs of real-world projects applying the patterns in two different industries.}, keywords = {API Design Patterns}, isbn = {9780137670017}, url = {https://api-patterns.org}, author = {Olaf Zimmermann and Mirko Stocker and Daniel L{\"u}bke and Uwe Zdun 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 {2021:europlop:api-fragments, title = {From OpenAPI Fragments to API Pattern Primitives and Design Smells}, booktitle = {European Conference on Pattern Languages of Programs (EuroPLoP{\textquoteright}21)}, year = {2021}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Virtual Kloster Irsee, Germany}, abstract = {In the past few years, the OpenAPI Specification (OAS) has emerged as a standard description language for accurately modeling Web APIs. Today, thousands of OpenAPI descriptions can be found by mining open source repositories. In this paper, we attempt to exploit these artifacts to extract commonly occurring building blocks used in Web API structures, in order to assist Web API designers in their modelling task. Our work is based on a fragmentation mechanism, that starts from OpenAPI descriptions of Web APIs to extract their structures, then fragment these structures into smaller blocks. This approach enabled us to extract a large dataset of reoccurring fragments from a collection of 6619 API specifications. Such fragments have been found multiple times in the same or across different APIs. We have classified the most reoccurring fragments into four pattern primitives used to expose in the API access to collections of items. We distinguish for each primitive variants from design smells. This classification is based on the specific combinations of operations associated with the collection items and on an in-depth analysis of their natural language labels and descriptions. The resulting pattern primitives are intended to support designers who would like to introduce one or more collections for a specific class of items in their HTTP-based API.}, keywords = {API, API fragments, design smells, OpenAPI, patterns}, doi = {10.1145/3489449.3489998}, url = {https://zenodo.org/record/5727094$\#$.YZ97mFMo-0o}, author = {Souhaila Serbout and Cesare Pautasso and Uwe Zdun and Olaf Zimmermann} } @conference {2021:plop, title = {Patterns on Designing API Endpoint Operations}, booktitle = {28th Conference on Pattern Languages of Programs (PLoP{\textquoteright}21)}, year = {2021}, month = {October}, publisher = {ACM}, organization = {ACM}, address = {Virtual}, abstract = {Domain-driven design (DDD) is often applied when implementing microservices or communicating through APIs in distributed systems. APIs expose a published language that provides a view on entire domain models or subsets of such models. Hence, tactical DDD patterns such as Aggregate, Service, and Entity may not only structure API implementations, but also guide API specification work. In our previous work, we described endpoint-level patterns for this context. In this paper, we present three complementary patterns, namely Aggregated Domain Operation on API Endpoint, Event-Based API Endpoint Operation, and CRUD-Based API Operation. These patterns aim to derive API operations from the operations of Domain Services and Entities as well as Domain Events. We also discuss variants of these patterns, such as their combination with the patterns Command Query Responsibility Segregation (CQRS) and Publish/Subscribe. Our pattern mining work is based on a data set from an empirical study of 32 grey literature sources investigating practitioner views on deriving API designs from DDD models.}, keywords = {API, Domain-Driven Design}, author = {Apitchaka Singjai and Uwe Zdun and Olaf Zimmermann and Mirko Stocker and Cesare Pautasso} } @conference {2019:map:europlop, title = {Interface Evolution Patterns {\textemdash} Balancing Compatibility and Flexibility across Microservices Lifecycles}, booktitle = {24th European Conference on Pattern Languages of Programs (EuroPLoP 2019)}, year = {2019}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Irsee, Germany}, abstract = {Remote Application Programming Interfaces (APIs) are technology enablers for distributed system trends such as cloud-native application development. API providers find it hard to design their remote APIs so that they can be evolved easily; refactoring and extending an API while preserving backward compatibility is particularly challenging. If APIs are evolved poorly, clients are critically impacted; high costs to adapt and compensate for downtimes may result. For instance, if an API provider publishes a new incompatible API version, existing clients might break and not function properly until they are upgraded to support the new version. Hence, applying adequate strategies for evolving service APIs is one of the core problems in API governance, which in turn is a prerequisite for successfully integrating service providers with their clients in the long run. Although many patterns and pattern languages are concerned with API and service design and related integration technologies,patterns guiding the evolution of APIs are missing to date. Extending our pattern language on Microservice API Patterns (MAP), we introduce a set of patterns focusing on API evolution strategies in this paper: API Description, Version Identifier, Semantic Versioning, Eternal Lifetime Guarantee, Limited Lifetime Guarantee, Two in Production, Aggressive Obsolescence, and Experimental Preview.The patterns have been mined from public Web APIs and industry projects the authors have been involved in.}, keywords = {API, API Evolution, Microservices, patterns}, doi = {10.1145/3361149.3361164}, url = {https://dl.acm.org/citation.cfm?id=3361164}, author = {Daniel L{\"u}bke and Olaf Zimmermann and Cesare Pautasso and Uwe Zdun} } @conference {2018:map:icsoc, title = {Guiding Architectural Decision Making on Quality Aspects of Microservice APIs}, booktitle = {16th International Conference on Service-Oriented Computing (ICSOC 2018)}, volume = {11236}, year = {2018}, month = {November}, pages = {73-89}, publisher = {Springer}, organization = {Springer}, address = {Hangzhou, Zhejiang, China}, abstract = {Microservice APIs represent the client perspective on microservice-based software architecture design and related practices. Major issues in API design concern the quality aspects of the API. However, it is not well understood today what the established practices related to those quality aspects are, how these practices are related, and what the major decision drivers are. This leads to great uncertainty in the design process. In this paper, we report on a qualitative, in-depth study of 31 widely used APIs plus 24 API specifications, standards, and technologies. In our study we identified six recurring architectural design decisions in two API design contexts with a total of 40 decision options and a total of 47 decision drivers. We modelled our findings in a formal, reusable architectural decision model. We measured the uncertainty in the resulting design space with and without use of our model, and found that a substantial uncertainty reduction can be potentially achieved by applying our model. }, keywords = {API, Microservices, quality}, doi = {10.1007/978-3-030-03596-9_5}, author = {Uwe Zdun and Mirko Stocker and Olaf Zimmermann and Cesare Pautasso and Daniel L{\"u}bke} } @conference {2018:map:europlop, title = {Interface Quality Patterns --- Crafting and Consuming Message-Based Remote APIs}, booktitle = {23rd European Conference on Pattern Languages of Programs (EuroPLoP)}, year = {2018}, month = {July}, publisher = {ACM}, organization = {ACM}, address = {Kloster Irsee, Germany}, abstract = {The design and evolution of Application Programming Interfaces (APIs) in microservices architectures is challenging. General design issues in integration and programming have been covered in great detail in many pattern languages since the beginnings of the patterns movement, and service-oriented infrastructure design patterns have also been published in the last decade. However, the interface representations (i.e., the content of message payloads) have received less attention. We presented five structural representation patterns in our previous work; in this paper we continue our coverage of the API design space and propose five interface quality patterns that deal with the observable aspects of quality-attribute-driven interface design for efficiency, security, and manageability: An API Key allows API providers to identify clients. Providers may offer rich data contracts in their responses, which not all consumers might need. A Wish List allows the client to request only the attributes in a response data set that it is interested in. If a client makes many API calls, the provider can employ a Rate Limit and bill clients according to a specified Rate Plan . A provider has to provide a high-quality service while at the same time having to use its available resources economically. The resulting compromise is expressed in a provider{\textquoteright}s Service Level Agreement. }, keywords = {interfaces, Microservices, patterns, quality}, author = {Mirko Stocker and Olaf Zimmermann and Daniel L{\"u}bke and Uwe Zdun and Cesare Pautasso} }