@demo {2022:ecsa:expresso,
	title = {ExpressO: From Express.js implementation code to OpenAPI interface descriptions},
	year = {2022},
	month = {September},
	pages = {29{\textendash}44},
	publisher = {Springer},
	abstract = {This tool demo paper brings forward a new CLI tool called ExpressO for developers who need to analyze a Web API implemented using the Express.js framework and automatically extract a specification written in the standard OpenAPI interface description language. The specification includes all of the implemented endpoints along with their response status codes and path and query parameters. Developers can use it to automatically determine whether the interface of a Web API matches its implementation based on the Express.js framework. The tool has been released on the npm component registry as {\textquoteleft}expresso-api{\textquoteright}.

},
	keywords = {API, express.js, OpenAPI},
	doi = {10.1007/978-3-031-36889-9_4},
	author = {Souhaila Serbout and Alessandro Romanelli and Cesare Pautasso}
}
@book {2021:bapie,
	title = {Beautiful API Evolution},
	year = {2021},
	publisher = {LeanPub},
	organization = {LeanPub},
	abstract = {This book presents the catalog of a virtual exhibition featuring different visualizations of the structural evolution of 51 Web APIs of different sizes and shapes, showing how they mostly grow but sometimes also shed some dead branches over the years.

The diagrams are drawn based on the exact OpenAPI specifications as they were versioned on some open source repository.

While there are many books on how to improve the design of existing APIs, the goal of this book is to show a small sample of actual API designs undergoing change. Learn from these examples to avoid false starts and discover which structures turn out to be stable over the years.

All APIs represented are Web APIs: they come from the age when many attempted with very different results to use the HTTP protocol to remotely invoke software delivered as a service.

The APIs have been selected mainly due to their visual appearance.},
	keywords = {API, API Evolution, visualization},
	url = {https://leanpub.com/beautiful-api-evolution/},
	author = {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}
}
@inbook {2020:restalk:ms,
	title = {Modeling Microservice Conversations with RESTalk},
	booktitle = {Microservices},
	year = {2020},
	pages = {129--146},
	publisher = {Springer},
	organization = {Springer},
	abstract = {Microservices are characterized by their small size and low degree of coupling. As a consequence, building microservice architectures requires composing multiple microservices and determine how they interact to achieve a given client{\textquoteright}s goal. In this chapter we introduce the concept of RESTful conversation, whereby clients or API gateways perform multiple basic HTTP request/response interactions with one or more microservice APIs. To represent possible sequences of interactions, we introduce the RESTalk visual notation, as well as its textual DSL, and the corresponding metamodel, and show how it can be used to complement existing structural approaches to represent RESTful APIs, such as the OpenAPI Specification. To reveal the degree of coupling between clients and microservices, the language supports the concept of hyperlink flow, showing whether, within a conversation, the links embedded into responses provided by a microservice are used by the client/API gateway to form the subsequent requests.},
	keywords = {API, conversation, Microservices, RESTalk},
	doi = {10.1007/978-3-030-31646-4_6},
	author = {Ana Ivanchikj 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}
}
@demo {2018:icsoc:demo:electra,
	title = {ELeCTRA: induced usage limitations calculation in RESTful APIs},
	year = {2018},
	month = {November},
	publisher = {Springer},
	address = {Hangzhou, Zhejiang, China},
	abstract = {As software architecture design is evolving to microservice paradigms, RESTful APIs become the building blocks of applications. In such a scenario, a growing market of APIs is proliferating and developers face the challenges to take advantage of this reality. For an example, third-party APIs typically define different usage limitations depending on the purchased Service Level Agreement (SLA) and, consequently, do- ing a manual limitation analysis of external APIs and their impact in a microservice architecture is a complex and tedious task. In this demonstration paper, we present ELeCTRA, a tool to automate the analysis of induced limitations in an API, derived from its usage of external APIs with limitations. Specifically, this tools takes the structural, conversational and SLA specifications of the API, generates a visual dependency graph and translates the problem into a constraint satisfaction optimization problem (CSOP) to obtain the optimal usage limitations.},
	keywords = {API, demo, REST},
	author = {Antonio Gamez-Diaz and Pablo Fernandez and Cesare Pautasso and Ana Ivanchikj and Antonio Ruiz-Cortes}
}
@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 {www2018:liquidjs,
	title = {The Liquid User Experience API},
	booktitle = {The Web Conference (WWW2018)},
	year = {2018},
	month = {April},
	pages = {767-774},
	publisher = {ACM},
	organization = {ACM},
	address = {Lyon, France},
	abstract = {In the past years the average number of Web-enabled devices owned by each user has significantly increased. Liquid Web applications enable users to take advantage of all their devices sequentially to migrate their running applications across them or simultaneously when running different views of the same application at the same time on each device. Developers of liquid Web application need to control how to expose the liquid behavior of their cross-device Web applications to the users. To do so, they can use the API of Liquid.js we describe in this paper. Liquid.js is a framework for building component-based rich Web applications which run across multiple Web-enabled devices. The framework is based on technologies such as Polymer, WebRTC, WebWorkers, PouchDB and Yjs. Liquid.js helps to build decentralized Web applications whose components can seamlessly flow directly between Web browsers carrying along their execution state. The Liquid.js API gives developers fine-grained control over the liquid user experience primitives, device discovery, and the lifecycle of liquid Web components. },
	keywords = {API, liquid software, web components},
	doi = {10.1145/3184558.3188738},
	author = {Andrea Gallidabino and Cesare Pautasso}
}
@inproceedings {2018:wesoacs,
	title = {May Contain Nuts: The Case for API Labels},
	year = {2018},
	month = {September},
	address = {Como, Italy},
	abstract = {As APIs proliferate, managing the constantly growing and evolving API landscapes inside and across organizations becomes a challenge. Part of the management challenge is for APIs to be able to describe themselves, so that users and tooling can use descriptions for finding and filtering APIs. A standardized labeling scheme can help to cover some of the cases where API self-description allows API landscapes to become more usable and scalable. In this paper we present the vision for standardized API labels, which summarize and represent critical aspects of APIs. These aspect allow consumers to more easily become aware of the kind of dependency they are going to establish with the service provider when choosing to use them. API labels not only summarize critical coupling factors, but also can include claims that require to be validated by trusted third parties.},
	keywords = {API, API Labels},
	author = {Cesare Pautasso and Erik Wilde}
}
