@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 {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} } @article {2018:ieeecloud:bac, title = {Consistent Disaster Recovery for Microservices: the BAC Theorem}, journal = {IEEE Cloud Computing}, volume = {5}, year = {2018}, month = {January/February}, pages = {49-59}, abstract = {How do you back up a microservice? You dump its database. But how do you back up an entire application decomposed into microservices? In this article, we discuss the tradeoff between the availability and consistency of a microservice-based architecture when a backup of the entire application is being performed. We demonstrate that service designers have to select two out of three qualities: backup, availability, and/or consistency (BAC). Service designers must also consider how to deal with consequences such as broken links, orphan state, and missing state.}, keywords = {availability, BAC theorem, consistency, disaster recovery, Microservices}, doi = {10.1109/MCC.2018.011791714}, url = {http://ieeexplore.ieee.org/document/8327550/}, author = {Guy Pardon and Cesare Pautasso and Olaf Zimmermann} } @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} } @article {2018:ieeesw, title = {The Web as a Software Connector: Integration Resting on Linked Resources}, journal = {IEEE Software}, volume = {35}, year = {2018}, month = {January/February}, pages = {93 - 98}, abstract = {The web, seen as a graph of linked resources shared between microservices, can serve as an integration style. It offers unique characteristics and possibilities regarding dataflow, control flow, and other qualities, compared to file transfer, shared databases, remote procedure calls, and asynchronous messaging. Carrying these insights in your toolbox will make you aware of all the options to consider next time you build loosely coupled integrated systems.}, keywords = {coupling, REST, software architecture}, doi = {10.1109/MS.2017.4541049}, url = {http://ieeexplore.ieee.org/document/8239944/}, author = {Cesare Pautasso and Olaf Zimmermann} } @article {2017:sw:ms1, title = {Microservices in Practice (Part 1): Reality Check and Service Design}, journal = {IEEE Software}, volume = {34}, year = {2017}, month = {January-February}, pages = {91-98}, keywords = {Microservices}, doi = {10.1109/MS.2017.24}, url = {http://ieeexplore.ieee.org/document/7819415/}, author = {Cesare Pautasso and Olaf Zimmermann and Mike Amundsen and James Lewis and Nicolai Josuttis} } @article {2017:sw:ms2, title = {Microservices in Practice (Part 2): Service Integration and Sustainability}, journal = {IEEE Software}, volume = {34}, year = {2017}, month = {March-April}, pages = {97-104}, keywords = {Microservices}, doi = {10.1109/MS.2017.56}, url = {http://ieeexplore.ieee.org/document/7888407/}, author = {Cesare Pautasso and Olaf Zimmermann and Mike Amundsen and James Lewis and Nicolai Josuttis} } @article {swinsight:2016:janfeb, title = {A Decade of Enterprise Integration Patterns: A Conversation with the Authors}, journal = {IEEE Software}, volume = {1}, year = {2016}, month = {January-February}, pages = {13-19}, abstract = {Department editors Olaf Zimmerman and Cesare Pautasso interview Gregor Hohpe and Bobby Woolf, authors of Enterprise Integration Patterns. They discuss the book{\textquoteright}s impact, pattern language design, message-oriented middleware, integration technology{\textquoteright}s evolution, and the authors{\textquoteright} future plans. }, keywords = {Enterprise Integration Patterns}, doi = {http://doi.ieeecomputersociety.org/10.1109/MS.2016.11}, url = {http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=\&arnumber=7368007}, author = {Olaf Zimmermann and Cesare Pautasso and Gregor Hohpe and Bobby Woolf} } @article {2015:ieeesoftware:insights, title = {Seeking Your Insights}, volume = {32}, year = {2015}, month = {March-April}, pages = {7--9}, keywords = {Software Engineering Practice}, issn = {0740-7459}, doi = {http://dx.doi.org/10.1109/MS.2015.47}, url = {https://ieeexplore.ieee.org/document/7057623/?arnumber=7057623}, author = {Cesare Pautasso and Olaf Zimmermann} } @inproceedings {saw:2010:shark, title = {Architectural decision modeling with reuse}, year = {2010}, month = {May}, pages = {13 - 20}, publisher = {ACM}, address = {Cape Town, South Africa}, abstract = {Architectural decision modeling aims at supporting the software architecture design process by capturing a reusable body of architectural knowledge. Whereas significant progress has been made towards this vision, there still remains a number of open problems. This paper outlines selected research challenges and opportunities related to knowledge capturing and sharing, model evolution and verification, and the integration of the architectural design process with existing software development methodologies. Our goal is to start a discussion on a roadmap for future research on reusable modeling of architectural decisions.}, keywords = {architectural decisions, SAW}, isbn = {9781605589671}, doi = {10.1145/1833335.1833338}, author = {Marcin Nowak and Cesare Pautasso and Olaf Zimmermann} } @conference {www08restsoap, title = {RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision}, booktitle = {17th World Wide Web Conference (WWW 2008)}, year = {2008}, month = {April}, pages = {805-814}, publisher = {ACM}, organization = {ACM}, address = {Beijing, China}, abstract = {Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS-* standards may be in sight: advocates of REpresentational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to simplify the plumbing required to build service-oriented architectures. In this paper we objectify the WS-* vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences in the consequences of certain decisions in terms of resulting development and maintenance costs. Our comparison helps technical decision makers to assess the two integration styles and technologies more objectively and select the one that best fits their needs: REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing. }, keywords = {architectural decisions, REST, SOAP, Web services}, doi = {10.1145/1367497.1367606}, author = {Cesare Pautasso and Olaf Zimmermann and Frank Leymann} } @conference {adkwik:2007:seke, title = {ADkwik: Web 2.0 Collaboration System for Architectural Decision Engineering}, booktitle = {Nineteenth International Conference on Software Engineering and Knowledge Engineering (SEKE 2007)}, year = {2007}, month = {July}, pages = {255-260}, address = {Boston, USA}, abstract = {Capturing and sharing software architecture design rationale has always been particularly challenging in complex application domains such as enterprise computing. Facing the ongoing acceleration of technology innovation and economic forces such as outsourcing and offshoring, conservative knowledge management practices and existing tools are no longer sufficient, offering only rudimentary support for knowledge exchange and collaboration on the Internet. In this paper, we present ADkwik, a Web 2.0 collaboration system supporting the cooperative decision making work of software architects. We describe the realization of ADkwik as a situational application wiki and discuss initial evaluation results. Thanks to its ease of use, ADkwik has already shown concrete benefits to its users, including rapid team orientation, tangible decision making advice, and simplification of asset harvesting.}, keywords = {architectural decisions}, author = {Nelly Schuster and Olaf Zimmermann and Cesare Pautasso} }