{ "version": "https://jsonfeed.org/version/1", "title": "Cesare Pautasso - Publications", "home_page_url": "http://www.pautasso.org/", "feed_url": "http://www.pautasso.org/biblio/feed.json", "description": "Publication list of Cesare Pautasso", "icon": "http://www.pautasso.org/img/CesarePautasso.jpg", "author": { "name": "Cesare Pautasso", "url": "http://www.pautasso.org/" }, "items": [ { "id": "biblio/2025/ese", "html_content": "", "url": "../biblio/2025/ese", "title": "Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models – A Controlled Experiment", "summary": "While microservice architectures have become a widespread option for designing distributed applications, designing secure microservice systems remains challenging. Although various security-related guidelines and practices exist, these systems\\textquoteright sheer size, complex communication structures, and polyglot tech stacks make it difficult to manually validate whether adequate security tactics are applied throughout their architecture.\nTo address these challenges, we have devised a novel solution that involves the automatic generation of security-annotated software decomposition models and the utilization of security-based metrics to guide software architectures through the assessment of security tactics employed within microservice systems. To evaluate the effectiveness of our artifacts, we conducted a controlled experiment where we asked 60 students from two universities and ten experts from the industry to identify and assess the security features of two microservice reference systems. During the experiment, we tracked the correctness of their answers and the time they needed to solve the given tasks to measure how well they could understand the security tactics applied in the reference systems.\nOur results indicate that the supplemental material significantly improved the correctness of the participants\\textquoteright answers without requiring them to consult the documentation more. Most participants also stated in a self-assessment that their understanding of the security tactics used in the systems improved significantly because of the provided material, with the additional diagrams considered very helpful. In contrast, the perception of architectural metrics varied widely. We could also show that novice developers benefited most from the supplementary diagrams. In contrast, senior developers could rely on their experience to compensate for the lack of additional help. Contrary to our expectations, we found no significant correlation between the time spent solving the tasks and the overall correctness score achieved, meaning that participants who took more time to read the documentation did not automatically achieve better results. As far as we know, this empirical study is the first analysis that explores the influence of security annotations in component diagrams to guide software developers when assessing microservice system security.", "date_modified": "2025-01-01T00:00:00Z", "author": { "name": "Patric Genfer" } }, { "id": "biblio/2025/icsa", "html_content": "", "url": "../biblio/2025/icsa", "title": "Mining Security Documentation Practices in OpenAPI Descriptions", "date_modified": "2025-02-28T23:00:00Z", "author": { "name": "Diana Carolina Muñoz Hurtado" } }, { "id": "biblio/2024/plop", "html_content": "", "url": "../biblio/2024/plop", "title": "Dark Patterns for Unethical Software Engineering", "summary": "Unethical software engineers write software to satisfy harmful requirements. While patterns promote beneficial solutions to recurring problems, dark patterns intentionally introduce harmful solutions. In this paper we present a collection of 16 dark patterns widely used by unethical software engineers to violate users privacy (email pixel injector, stealthy input logger), pursue monetization at all costs (aggressive advertiser, ad-blocker detector, pay to win, artificial scarcity hoarder, DRM rug puller, obsolescence planner), commit digital frauds (cybersquatter, sneaky terms degrader, interoperability breaker), manipulate search rankings (fake review generator, search ranking kickbacker), and engage in unethical artificial intelligence practices (training data harvester, bot pretender, deceptive deepfaker). By discussing the ethical consequences of each pattern we aim to raise awareness about them and encourage their avoidance by ethical software engineers, architects and practitioners.", "date_modified": "2024-09-30T22:00:00Z", "author": { "name": "Cesare Pautasso" } }, { "id": "biblio/2024/bpm", "html_content": "", "url": "../biblio/2024/bpm", "title": "Transparent Transaction Ordering in Blockchain-based Collaborative Processes", "summary": "Blockchain technology offers a promising solution for overcoming trust-related challenges, such as transparency in interorganizational collaborative processes. However, since the ordering of transactions in a block can affect the outcome of a process instance, fairness and transparency concerns regarding block selection may arise. This paper presents a consensus-agnostic approach to promote transparency in transaction ordering in blockchain-based business processes. The approach allows participants to align the execution order of their transactions with their business objectives, effectively mitigating the lack of transparency associated with the arbitrary selection and ordering of transactions during block selection. Our experiments reveal that the increased transparency mitigates the risks of suppression and displacement attacks at the cost of introducing additional latency and cost.", "image": "/biblio-covers/fc4mc-bpm2024.png", "date_modified": "2024-08-31T22:00:00Z", "author": { "name": "Hassan Atwi" } }, { "id": "biblio/2024/jwe", "html_content": "", "url": "../biblio/2024/jwe", "title": "How Are Web APIs Versioned in Practice? A Large-Scale Empirical Study", "summary": "Web APIs form the cornerstone of modern software ecosystems, facilitating seamless data exchange and service integration. Ensuring the compatibility and longevity of these APIs is paramount. This study delves into the intricate realm of API versioning practices, a crucial mechanism for managing API evolution. Exploring an expanded and diverse dataset of 603 293 APIs specifications created during the 2015–2023 timeframe and gathered from four different sources, we examined the adoption of the following versioning practices: Metadata-based, URL-based, Header-based and Dynamic versioning, with one or more versions in production. API developers use more than 50 different version identifier formats to encode information about the changes introduced with respect to the previous version (i.e., semantic versioning), about when the version was released (i.e., age versioning) and about which phase of the API development lifecycle the version belongs (i.e., stable vs. preview releases).", "image": "/biblio-covers/apiace-jwe-2024.png", "date_modified": "2024-07-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2024/ecsa", "html_content": "", "url": "../biblio/2024/ecsa", "title": "OAS2Tree: Visual API-First Design", "summary": "OAS2Tree is a tool designed to transform OpenAPI Specification (OAS) documents into tree-like visualizations, aiding in the understanding and navigation of the structure of REST APIs. By converting the detailed, verbose, and often complex OAS files into a visual tree structure, OAS2tree simplifies the comprehension of a Web API, highlighting the hierarchical relationships between endpoints, operations, and parameters. This visual representation is particularly useful for developers and stakeholders who need a quick overview of an API without delving into the intricate details of its technical specifications. OAS2tree can be integrated into the IDE through a Visual Studio code extension or used as a standalone web application. The tool currently has about 400 users and has been used on teaching, research, and development projects. In this paper, we present the design and implementation of OAS2tree, highlighting its features and use cases. We also highlight the limitations of the current version and discuss future improvements and potential extensions.", "image": "/biblio-covers/apiace-ecsa2024-oas2tree.png", "date_modified": "2024-08-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2024/msr", "html_content": "", "url": "../biblio/2024/msr", "title": "APIstic: A Large Collection of OpenAPI Metrics", "summary": "In the rapidly evolving landscape of web services, the significance of efficiently designed and well-documented APIs is paramount. In this paper, we present APIstic an API analytics dataset and exploration tool to navigate and segment APIs based on an extensive set of precomputed metrics extracted from OpenAPI specifications, sourced from GitHub, SwaggerHub, BigQuery and APIs.guru.\nThese pre-computed metrics are categorized into structure, data model, natural language description, and security metrics.\nThe extensive dataset of varied API metrics provides crucial insights into API design and documentation for both researchers and practitioners. Researchers can use APIstic as an empirical resource to extract refined samples, analyze API design trends, best practices, smells, and patterns. For API designers, it serves as a benchmarking tool to assess, compare, and improve API structures, data models, and documentation using metrics to select points of references among 1,275,568 valid OpenAPI specifications.\nThe paper discusses potential use cases of the collected data and presents a descriptive analysis of selected API analytics metrics. ", "image": "/biblio-covers/apiace-msr2024-apistic.png", "date_modified": "2024-03-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2024/ieeesw", "html_content": "", "url": "../biblio/2024/ieeesw", "title": "Continuous Integration and Delivery in Open Source Development and Pattern Publishing: Lessons Learned With Tool Setup and Pipeline Evolution", "summary": "Every software project that aims to deliver high quality output needs a continuous integration setup. However, once the build pipeline is working, one cannot rest and take things for granted. Over long periods of time, tools come and go, and even if they remain the same, vendors often tinker with their pricing model. Lacking standardized and portable build configurations, it is critical to minimize the coupling between what needs to be built, how and where it gets built.", "date_modified": "2024-01-31T23:00:00Z", "author": { "name": "Olaf Zimmermann" } }, { "id": "biblio/2024/asianplop", "html_content": "", "url": "../biblio/2024/asianplop", "title": "Decentralized Task Execution Patterns", "summary": "Decentralized task execution requires to assign planning, execution and control roles and responsibilities to at least two distinct parties. These include making decisions about \\textquoteleft\\textquoteleftwho does what when\\textquoteright\\textquoteright so that one party can track the progress and the outcome of tasks executed by another party. In this paper we outline the design space for decentralized task execution by presenting 18 different patterns, going from imperative task execution all the way to autonomous task execution. We will distinguish how decisions about who performs a task, what needs to be done and when to do it can be made by different parties and how these alternative decision-making locations impact the interactions between the parties responsible to plan, execute and control the task execution. The patterns are applicable within human organizations with many actors delegating or performing multiple tasks but also to fully automated systems, e.g., distributed operating systems, intelligent autonomous vehicles, blockchain-based workflow engines or high throughput job schedulers.", "image": "/biblio-covers/asianplop2024.png", "date_modified": "2024-02-29T23:00:00Z", "author": { "name": "Cesare Pautasso" } }, { "id": "biblio/2024/icwe", "html_content": "", "url": "../biblio/2024/icwe", "title": "How Many Web APIs Evolve Following Semantic Versioning?", "summary": "More and more Web APIs use semantic versioning to represent the impact of changes on clients depending on previous versions. Our goal is to provide insights about the extent to which evolving Web APIs align with semantic versioning rules. In this paper we present the results of an empirical study on the descriptions of 3 075 Web APIs, which released at least one new version throughout their history. The APIs descriptions were mined by retrieving 132 909 commits from 2 028 different open source GitHub repositories. We systematically collected and examined 506 273 changes of 195 different types released within 16 053 new API versions. We classified whether each change is likely to break clients or not, and checked whether the corresponding version identifier has been updated following semantic versioning rules. The results indicate that in the best case, only 517 APIs consistently release major upgrades when introducing breaking changes, while 1 970 APIs will not always correctly inform their clients about breaking changes released as part of minor or patch-level upgrades. We also detected 927 APIs which use a backwards-compatible evolution strategy, as they never introduce any breaking change throughout their history.", "image": "/biblio-covers/apiace-icwe2024.png", "date_modified": "2024-05-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2023/bpm", "html_content": "", "url": "../biblio/2023/bpm", "title": "Loose Collaborations on the Blockchain: Survey and Challenges", "summary": "Blockchain technology has emerged as a promising infrastructure for enabling collaboration between mutually distrustful organizations. The enactment of blockchain-based collaborative processes typically requires a profound understanding of the process being executed, limiting support for flexible processes that cannot be fully prespecified at design time. To overcome this limitation, support for looseness, dealing with the configuration and execution of underspecified processes, is essential. In this paper, we conduct a systematic literature review to examine looseness support for blockchain-based collaborative processes from a behavioral and organizational perspective. In addition, we identify open research challenges to pave the way for further research in this area.", "image": "/biblio-covers/fc4mc-bpm2023.png", "date_modified": "2023-08-31T22:00:00Z", "author": { "name": "Tom Lichtenstein" } }, { "id": "biblio/2023/vissoft", "html_content": "", "url": "../biblio/2023/vissoft", "title": "Interactively exploring API changes and versioning consistency", "summary": "Application Programming Interfaces (APIs) evolve\nover time. As they change, they are expected to be versioned\nbased on how changes might affect their clients. In this paper, we\npresent two novel visualizations specifically designed to represent\nall structural changes and the level of adherence to semantic\nversioning practices over time. They can also serve for characterizing and comparing the evolution history of different Web\nAPIs. The API VERSION CLOCK helps to visualize the sequence\nof API changes over time and highlight inconsistencies between\nmajor, minor, or patch version changes and the corresponding\nintroduced breaking or non-breaking changes applied to the\nAPI. The API CHANGES overview aggregates all changes to\nan OpenAPI (OAS) description, highlighting the unstable vs.\nthe stable elements of the API over its entire history. Both\nvisualizations can be automatically created using the APICTURE,\na command-line and web-based tool that analyzes the histories\nof git code repositories containing OAS descriptions, extracting\nthe necessary data for generating visualizations and computing\nmetrics related to API evolution and versioning. The visualizations have been successfully applied to classify, compare, and\ninteractively explore the multi-year evolution history of APIs with\nup to hundreds of individual commits.", "image": "/biblio-covers/apiace-vissoft2023.png", "date_modified": "2023-09-30T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2024/sa-education", "html_content": "", "url": "../biblio/2024/sa-education", "title": "A Better Way to Teach Software Architecture", "summary": "Software architecture education is a weak spot in many undergraduate programs in computer science and software engineering. While the concepts and practices used by software architects in industry are rich and varied, transferring this expertise into a university classroom has proved problematic. Bridging the gap between industry and academia requires ongoing, often heroic, effort. This is a \\textquotedblleftchicken and egg\\textquotedblright problem: Because there is a lack of good teaching materials, architecture is seldom taught, and because it is seldom taught, there has been little incentive to create good materials. We would like to change that. Our goal is to establish guidelines for how software architecture practices should be taught\\textemdashboth technical and non-technical topics\\textemdashand to suggest appropriate teaching methods to best prepare students to be software architects in practice.", "date_modified": "2023-01-01T00:00:00Z", "author": { "name": "Rick Kazman" } }, { "id": "biblio/2024/sa-empirical", "html_content": "", "url": "../biblio/2024/sa-empirical", "title": "An Empirical Basis for Software Architecture Research", "summary": "Despite the clear need for and importance of performing empirical studies as part of software architecture research, there is still a lack of curated, standardized, clean, well-maintained, documented, easily accessible, reusable, and shared datasets. In this chapter, we provide an overview of the problems, of the motivations, and of the opportunities currently related to mining and sharing datasets for researchers in software architecture. We first explore and describe which artifacts should be included into such datasets, such as code, documentation, and requirements, but also including other architecturally relevant artifacts, such as architectural decision records, models, and other kinds of documentation. This information can be complemented with revision history logs, social metadata, and email or chat discussion archives. The availability of such datasets would enable not only architectural reconstruction studies but would also help to catalyze broader and more ambitious program of empirical studies in software architecture research.", "date_modified": "2023-01-01T00:00:00Z", "author": { "name": "Rick Kazman" } }, { "id": "biblio/2023/iedge-liquid", "html_content": "", "url": "../biblio/2023/iedge-liquid", "title": "A brief history of liquid software", "summary": "The concept of liquid software, i.e., software with flexible deployment, over the past two decades has appeared in the fields of edge computing, Internet of Things (IoT), Human-Computer Interaction, DevOps and Web engineering. In this paper, we survey, compare, and provide a comprehensive definition of liquid software by analyzing how the metaphor has been used in existing literature and identifying gaps and inconsistencies in the current vs. past understanding of the concept. \nOverall, liquid software can be seamlessly deployed and redeployed within a dynamic and distributed runtime environment in response to changes applied to the set of available devices and to the software itself. \nLiquid software has been introduced in the context of active networks and intelligent environments, it has been applied to describe the user interaction with multi and cross-device user interfaces, it has found a promising foundation in Web technology, continuous software delivery pipelines, as well as isomorphic software architectures running across the IoT, edge and Cloud continuum.", "image": "/biblio-covers/iedge2023-a-brief-history-of-liquid-software.png", "date_modified": "2023-06-30T22:00:00Z", "author": { "name": "Cesare Pautasso" } }, { "id": "biblio/2023/europlop", "html_content": "", "url": "../biblio/2023/europlop", "title": "API Rate Limit Adoption - A Pattern Collection", "image": "/biblio-covers/apiace-europlop2023.png", "date_modified": "2023-06-30T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2023/icwe-api-versioning", "html_content": "", "url": "../biblio/2023/icwe-api-versioning", "title": "An empirical study of Web API versioning practices", "summary": "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.\nIn 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.\nOverall 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.", "image": "/biblio-covers/apiace-icwe2023-versioning.png", "date_modified": "2023-05-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2023/icwe-liquidai", "html_content": "", "url": "../biblio/2023/icwe-liquidai", "title": "LiquidAI: Towards an Isomorphic AI/ML System Architecture for the Cloud-Edge Continuum", "summary": "A typical Internet of Things (IoT) system consists of a large number of different subsystems and devices, including sensors and actuators, gateways that connect them to the Internet, cloud services, end-user applications and analytics. Today, these subsystems are implemented with a broad variety of programming technologies and tools, making it difficult to migrate functionality from one subsystem to another. In our earlier papers, we have predicted the rise of \\emphisomorphic IoT system architectures in which all the subsystems can be developed with a consistent set of technologies. \nIn this paper we expand the same research theme to machine learning technologies, highlighting the need to use ML in a consistent and uniform fashion across the entire Cloud-Edge continuum. ", "image": "/biblio-covers/icwe2023-liquidai.png", "date_modified": "2023-05-31T22:00:00Z", "author": { "name": "Kari Systa" } }, { "id": "biblio/2023/2023map", "html_content": "", "url": "../biblio/2023/2023map", "title": "Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges", "summary": "Proven Patterns for Designing Evolvable High-Quality APIs--For Any Domain, Technology, or Platform\n\nAPIs 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.\n\nIn 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.", "image": "/biblio-covers/map.png", "date_modified": "2023-01-01T00:00:00Z", "author": { "name": "Olaf Zimmermann" } }, { "id": "biblio/2022/sose-ccc", "html_content": "", "url": "../biblio/2022/sose-ccc", "title": "Cargo-Cult Containerization: A Critical View of Containers in Modern Software Development", "summary": "Software is increasingly developed and deployed using containers. While the concept of a container is conceptually straightforward, there are various issues to be considered while using them, ranging from technical details inside containers to the orchestration of containers that jointly form a meaningful application. In recent years, the use of containers has become so prevalent that developers have a tendency to resort to cargo-cult containerization – ritual adherence to the use of containers just because so many others are doing the same thing. In this paper, we study advantages and downsides of containers in modern- day software development. We foresee the use of containers to spread into new areas, including IoT systems and embedded devices. At the same time, we caution against indiscriminate use of containers, since excessive containerization can have adverse impacts on software maintenance and overall complexity of a system architecture.", "image": "/biblio-covers/sose2022-ccc.png", "date_modified": "2022-07-31T22:00:00Z", "author": { "name": "Tommi Mikkonen" } }, { "id": "biblio/2022/ecsa-expresso", "html_content": "", "url": "../biblio/2022/ecsa-expresso", "title": "ExpressO: From Express.js implementation code to OpenAPI interface descriptions", "summary": "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 'expresso-api'.", "image": "/biblio-covers/apiace-ecsa2022-expresso.png", "date_modified": "2022-08-31T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2022/icws", "html_content": "", "url": "../biblio/2022/icws", "title": "How Composable is the Web? An Empirical Study on OpenAPI Data model Compatibility", "summary": "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?\n\nThe paper presents an empirical study to determine the potential composability of a large collection of 20,587 public Web APIs by verifying their schemas' 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. \n\nTo 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.\n\nThe results indicate a relatively high number of compatible APIs when matching their data models only on the level of their elements' 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.", "image": "/biblio-covers/apiace-icws2022.png", "date_modified": "2022-06-30T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2022/sose-api", "html_content": "", "url": "../biblio/2022/sose-api", "title": "Impact of API Rate Limit on Reliability of Microservices-Based Architectures", "summary": "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 accurately predict the impact of Rate Limiting on the reliability of microservices-based architectures.", "image": "/biblio-covers/apiace-sose2022.png", "date_modified": "2022-07-31T22:00:00Z", "author": { "name": "Amine El Malki" } }, { "id": "biblio/2022/jwe", "html_content": "", "url": "../biblio/2022/jwe", "title": "A Large-scale Empirical Assessment of Web API Size Evolution", "summary": "Like any other type of software, also Web Application Programming Interfaces (APIs) evolve over time. In the case of widely used API, introducing changes is never a trivial task, because of the risk of breaking thousands of clients relying on the API. In this paper we conduct an empirical study over a large collection of OpenAPI descriptions obtained by mining open source repositories. We measure the speed at which Web APIs change and how changes affect their size, simply defined as the number of operations. The dataset of API descriptions was collected over a period of one year and includes APIs with histories spanning across up to 7 years of commits. The main finding is that APIs tend to grow, although some do reduce their size, as shown in the case study examples included in the appendix.", "image": "/biblio-covers/apiace-jwe-2022.png", "date_modified": "2022-10-31T23:00:00Z", "author": { "name": "Fabio Di Lauro" } }, { "id": "biblio/2022/sosym", "html_content": "", "url": "../biblio/2022/sosym", "title": "Live process modeling with the BPMN Sketch Miner", "summary": "BPMN Sketch Miner is a modeling environment for generating visual business process models starting from constrained natural language textual input. Its purpose is to support business process modelers who need to rapidly sketch visual BPMN models during interviews and design workshops, where participants should not only provide input but also give feedback on whether the sketched visual model represents accurately what has been described during the discussion. In this article, we present a detailed description of the BPMN Sketch Miner design decisions and list the different control flow patterns supported by the current version of its textual DSL. We also summarize the user study and survey results originally published in MODELS 2020 concerning the tool usability and learnability and present a new performance evaluation regarding the visual model generation pipeline under actual usage conditions. The goal is to determine whether it can support a rapid model editing cycle, with live synchronization between the textual description and the visual model. This study is based on a benchmark including a large number of models (1350 models) exported by users of the tool during the year 2020. The main results indicate that the performance is sufficient for a smooth live modeling user experience and that the end-to-end execution time of the text-to-model-to-visual pipeline grows linearly with the model size, up to the largest models (with 195 lines of textual description) found in the benchmark workload.", "image": "/biblio-covers/bpmn-sketch-miner-sosym2022.png", "date_modified": "2022-09-30T22:00:00Z", "author": { "name": "Ana Ivanchikj" } }, { "id": "biblio/2022/ecsa", "html_content": "", "url": "../biblio/2022/ecsa", "title": "To deprecate or to simply drop operations? An empirical study on the evolution of a large OpenAPI collection", "summary": "OpenAPI is a language-agnostic standard used to describe Web APIs which supports the explicit deprecation of interface features. To assess how APIs evolve over time and observe how their developers handle the introduction of breaking changes, we performed an empirical study on a dataset composed of more thanone million API operations described using OpenAPI and Swagger format. Our results focus on detecting breaking changes engendered by operations removal and whether and to which extent deprecation is used to warn clients and developers about dependencies they should no longer rely on. Out of the 41,627 APIs considered, we found only 263 (0.6) in which some operations are deprecated before being removed, while the developers of 10,242 (24.6%) of them directly remove operations without first informing their clients about the potentially breaking change. Furthermore, we found that only 5.2% of the explicit-deprecated operations and 8.0% of the deprecated-in-description operations end with a removal, suggesting a tendency to deprecate operations without removing them. Overall, we observed a low negative correlation between the relative amount of deprecated operations and the age of the corresponding APIs.", "image": "/biblio-covers/apiace-ecsa2022-deprecate.png", "date_modified": "2022-08-31T22:00:00Z", "author": { "name": "Fabio Di Lauro" } }, { "id": "biblio/2022/icsa", "html_content": "", "url": "../biblio/2022/icsa", "title": "Web APIs Structures and Data Models Analysis", "summary": "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. ", "image": "/biblio-covers/apiace-icsa2022.png", "date_modified": "2022-02-28T23:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/book/beautiful-api-evolution", "html_content": "", "url": "../biblio/book/beautiful-api-evolution", "title": "Beautiful API Evolution", "summary": "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.\n\nThe diagrams are drawn based on the exact OpenAPI specifications as they were versioned on some open source repository.\n\nWhile 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.\n\nAll 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.\n\nThe APIs have been selected mainly due to their visual appearance.", "image": "/biblio-covers/beautiful-api-evolution.png", "date_modified": "2021-01-01T00:00:00Z", "author": { "name": "Cesare Pautasso" } }, { "id": "biblio/book/beautiful-apis", "html_content": "", "url": "../biblio/book/beautiful-apis", "title": "Beautiful APIs", "summary": "This book presents the catalog of a virtual exhibition featuring the structural visualizations of 93 Web APIs of different sizes and shapes. The diagrams are drawn based on the exact API specification found on some open source repository.\n\nWhile there are many books on how to design good APIs, the goal of this book is to show a small sample of actual API designs. There is a lot that can be learned from them.\n\nAll APIs represented are Web APIs: they come from the time when many attempted with very different results to use the HTTP protocol to remotely invoke software delivered as a service.\n\nThe APIs have been selected mainly due to their visual appearance.", "image": "/biblio-covers/beautiful-apis.png", "date_modified": "2021-01-01T00:00:00Z", "author": { "name": "Cesare Pautasso" } }, { "id": "biblio/2021/europlop", "html_content": "", "url": "../biblio/2021/europlop", "title": "From OpenAPI Fragments to API Pattern Primitives and Design Smells", "summary": "In the past few years, the OpenAPI Specification (OAS) has emerged as a standard description language for accurately modeling Web APIs.\nToday, 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. \nSuch 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.", "date_modified": "2021-06-30T22:00:00Z", "author": { "name": "Souhaila Serbout" } }, { "id": "biblio/2021/computer", "html_content": "", "url": "../biblio/2021/computer", "title": "Isomorphic Internet of Things Architectures With Web Technologies", "summary": "Internet of Things development needs isomorphic software architectures, in which every kind of device can be programmed with a consistent set of implementation technologies, allowing applications and their components to be statically deployed or dynamically migrated without having to change their shape.", "date_modified": "2021-06-30T22:00:00Z", "author": { "name": "Tommi Mikkonen" } }, { "id": "biblio/2021/plop", "html_content": "", "url": "../biblio/2021/plop", "title": "Patterns on Designing API Endpoint Operations", "summary": "Domain-driven design (DDD) is often applied when implementing microservices or communicating through APIs in distributed\nsystems. APIs expose a published language that provides a view on entire domain models or subsets of such models. Hence,\ntactical DDD patterns such as Aggregate, Service, and Entity may not only structure API implementations, but also guide API\nspecification work. In our previous work, we described endpoint-level patterns for this context. In this paper, we present three\ncomplementary patterns, namely Aggregated Domain Operation on API Endpoint, Event-Based API Endpoint Operation, and\nCRUD-Based API Operation. These patterns aim to derive API operations from the operations of Domain Services and Entities\nas well as Domain Events. We also discuss variants of these patterns, such as their combination with the patterns Command\nQuery Responsibility Segregation (CQRS) and Publish/Subscribe. Our pattern mining work is based on a data set from an\nempirical study of 32 grey literature sources investigating practitioner views on deriving API designs from DDD models.", "image": "/biblio-covers/plop21-api.png", "date_modified": "2021-09-30T22:00:00Z", "author": { "name": "Apitchaka Singjai" } }, { "id": "biblio/2021/icwe-liquid", "html_content": "", "url": "../biblio/2021/icwe-liquid", "title": "Towards Seamless IoT Device-Edge-Cloud Continuum", "summary": "In this paper we revisit a taxonomy of client-side IoT software architectures that we presented a few years ago. We note that the emergence of inexpensive AI/ML hardware and new communication technologies are broadening the architectural options for IoT devices even further. These options can have a significant impact on the overall end-to-end architecture and topology of IoT systems, e.g., in determining how much computation can be performed on the edge of the network. We study the implications of the IoT device architecture choices in light of the new observations, as well as make some new predictions about future directions. Additionally, we make a case for isomorphic IoT systems in which development complexity is alleviated with consistent use of technologies across the entire stack, providing a seamless continuum from edge devices all the way to the cloud.", "date_modified": "2021-01-01T00:00:00Z", "author": { "name": "Taivalsaari" } }, { "id": "biblio/2021/icwe-full-stack", "html_content": "", "url": "../biblio/2021/icwe-full-stack", "title": "Full Stack is Not What It Used to Be", "summary": "The traditional definition of full stack development refers to a skill set that is required for writing software both for the frontend and backend of a web application or site. In recent years, the scope of full stack development has expanded significantly, though. Today, a full stack software developer is assumed to master various additional areas especially related to cloud infrastructure and deployment, message brokers and data analytics technologies. In addition, the emergence of Internet of Things (IoT) and the rapidly spreading use of AI/ML technologies are introducing additional skill set requirements. In this paper, we discuss the expectations for a modern full stack developer based on our industry observations, and argue that these expectations have significant implications for software and web engineering education.", "image": "/biblio-covers/icwe2021-fullstack.png", "date_modified": "2021-04-30T22:00:00Z", "author": { "name": "Antero Taivalsaari" } }, { "id": "biblio/2021/icwe-wasm", "html_content": "", "url": "../biblio/2021/icwe-wasm", "title": "WebAssembly Modules as Lightweight Containers for Liquid IoT Applications", "summary": "Going all the way to IoT with web technologies opens up the door to isomorphic IoT system architectures, which deliver flexible deployment and live migration of code between any device in the overall system. In this vision paper, we propose using WebAssembly to implement lightweight containers and deliver the required portability. Our long-term vision is to use the technology to support developers of liquid IoT applications offering seamless, hassle-free use of multiple devices.", "date_modified": "2021-04-30T22:00:00Z", "author": { "name": "Niko Mäkitalo" } }, { "id": "biblio/2021/icwe-api-evolution", "html_content": "", "url": "../biblio/2021/icwe-api-evolution", "title": "Towards Large-scale Empirical Assessment of Web APIs Evolution", "summary": "Web Application Programming Interfaces (APIs) decouple the internal implementation of a service from its consumers which can reuse and compose them to rapidly build new applications.\nMany Web APIs are described with the OpenAPI Specification (OAS). The goal of our research is to check the feasibility of using API descriptions found in public open source repositories to study how APIs evolve over time. To do so, we collected a large dataset of OAS documents by crawling open source repositories, we parsed the corresponding metadata and measured the API size in order to extract a simple model to track the lifecycle of API artifacts and observe common evolution behaviors. Our preliminary results indicate that only a subset of the APIs changes, but as opposed to the expectation that APIs should only grow to maintain backward compatibility we also detected a number of APIs with a more variable history. We also study the stability of API artifacts over time and whether APIs are more or less likely to change as they age.", "date_modified": "2021-04-30T22:00:00Z", "author": { "name": "Fabio Di Lauro" } }, { "id": "biblio/book/business-process-management", "html_content": "", "url": "../biblio/book/business-process-management", "title": "Business Process Modeling, Management, and Mining: visual lecture notes", "summary": "Processes are everywhere. Learn how to recognize them using process modeling, reconstruct them with process mining, improve them with process simulation, and run them with process automation. And yes, also visualize them with the Business Process Model and Notation (BPMN).\n\nThese are the revised and illustrated notes of the BPM3 lecture of the Master in Management and Informatics held at the Faculty of Informatics and Economics at USI Lugano, Switzerland during the Spring of 2020.\n\nThe book includes the slides and the script for all lectures:\n\n