@phdthesis {restalk:phd:ana.ivanchikj,
	title = {RESTalk: A Visual and Textual DSL for Modelling RESTful Conversations},
	year = {2021},
	month = {January},
	school = {USI},
	type = {PhD},
	address = {Lugano},
	abstract = {Digitalization is all around us, even more so in pandemic times where substantial part of our lives has been moved online. One of the key enablers of digitalization are the Application Programming Interfaces (APIs) which enable the communication and exchange of data between different systems. They abstract from the implementation details of the underlying systems and allow for the monetization of digital assets paving the way to innovative services, bringing together different business partners, even in traditionally closed sectors such as banking.

In this dissertation we focus on a particular type of APIs which conform to the REpresentation State Transfer (REST) architectural style constraints due to their dominance in the API landscape. Although Fielding defined REST as architectural style back in 2000, our state of the art review has identified a gap when it comes to modeling the behaviour of REST APIs. Existing approaches are not domain specific and as such fail to emphasise important facets in RESTful interactions. Since APIs need to satisfy multiple clients, it is not always possible to provide them with operations dedicated to achieving the specific goals of individual clients. Instead, clients often need to perform multiple interactions in a specific order to achieve their goals. We call the set of possible sequences of interactions to achieve a goal a RESTful conversation. 

Visualizing complex RESTful conversations in a domain specific model can help streamline their design by facilitating discussion and common knowledge sharing, but also by constraining the supported API behavior from the combinatorial set of all possible interaction sequences. This enables service providers to maintain and evolve their APIs. Visual models can also facilitate client developers{\textquoteright} understanding of a given API, and speed up the identification of the correct sequence of calls to be made given a goal. Based on our study of the characteristics of RESTful conversations, we introduce the design of RESTalk: a Domain Specific Language (DSL) for modelling the behaviour of REST APIs. The language supports single client to single server conversations, but also multiple clients talking to the same server in order to achieve a common goal, as well as composite layered conversations. We have designed RESTalk iteratively with a frequent feedback from users while modelling different use-cases. Since its targeted users are developers, we propose both a graphical and a textual syntax for the language. We take an innovative approach in the design of the textual grammar, which leverages on a mining algorithm to generate the alternative control flow of the RESTful conversation and on a graph layout algorithm to automatically produce the visual diagram. Thus, the textual DSL has a log-like form with a minimal use of keywords. It aims at decreasing the cognitive load of the modeler while increasing the efficiency of model generation. Further evaluations are necessary to verify the actual benefits of the textual DSL over the graphical DSL. We have evaluated the expressiveness of RESTalk with real-world examples of RESTful conversations and patterns, and performed controlled experiments to attempt to determine the effectiveness and efficiency of the visual diagrams in facilitating the understanding of a given API.
},
	keywords = {REST, RESTalk},
	author = {Ana Ivanchikj}
}
@article {2019:rest:sawq,
	title = {SAW-Q: a dynamic composition approach of REST services based on queue model},
	journal = {International Journal of Web and Grid Services},
	volume = {15},
	year = {2019},
	month = {January},
	pages = {29 - 58},
	abstract = {Service composition is one of the principles of service-oriented architecture; it enables reuse and allows developers to combine existing services in order to create new services that in turn can be part of another composition. Dynamic composition requires that service components are chosen from a set of services with equal or similar functionality at runtime and possibly automatically. The adoption of the REST services in the industry has led to a growing number of services of this type, many with similar functionality. The existing dynamic composition techniques are method-oriented whereas REST is resource-oriented and consider only traditional (WSDL/SOAP) services. We propose SAW-Q, an extension of simple additive weighting (SAW), as a novel dynamic composition technique that follows the principles of the REST style. Additionally, SAW-Q models quality attributes as a function of the actual service demand instead of the traditional constant values. Our model is much more accurate when compared to real implementation, positively improving the quality of dynamic service compositions.},
	keywords = {automatic composition, dynamic composition, quality of service, REST, SOA, Web services},
	doi = {10.1504/IJWGS.2019.096555},
	author = {Bellido, Jesus and Rosa Alarc{\'o}n and Cesare Pautasso and Carla Vairetti}
}
@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}
}
@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}
}
@conference {rest:2015:wicsa,
	title = {A conversation based approach for modeling REST APIs},
	booktitle = {12th Working IEEE / IFIP Conference on Software Architecture (WICSA 2015)},
	year = {2015},
	month = {May},
	address = {Montreal, Canada},
	abstract = {Conversations are a well-known concept in service design to describe complex interactions between a client and one or multiple services. The REST architectural style constrains the characteristics of clients, servers and their interactions in REST architectures which consequently has an impact on conversations in such systems. The relation between conversations and REST architectures and how such RESTful conversations can be characterized has not been studied in detail yet. In this paper we discuss the characteristics of conversations in REST architectures and introduce an initial set of commonly used conversation types. Based on this, we propose to use conversations as a modeling tool for the design of REST APIs at a higher level of abstraction. We also introduce a corresponding interaction centric metamodel for REST APIs. The characterization of RESTful conversations enables a new interaction centric viewpoint on REST architectures which can be also applied for modeling REST APIs on an abstraction level that enables users to focus on the essential functionality of their REST API.},
	keywords = {conversation, model-driven engineering, REST, RESTful conversation},
	url = {http://wicsa2015.org/wicsa-sessions.html$\#$WS5},
	author = {Florian Haupt and Frank Leymann and Cesare Pautasso}
}
@conference {ecsa2015:restcon,
	title = {Modeling RESTful Conversations with extended BPMN Choreography diagrams},
	booktitle = {9th European Conference on Software Architecture (ECSA 2015)},
	year = {2015},
	month = {September},
	publisher = {Springer},
	organization = {Springer},
	address = {Dubrovnik, Croatia},
	abstract = {RESTful Web APIs often make use of multiple basic HTTP interactions to guide clients towards their goal. For example, clients may get redirected towards related resources by means of hypermedia controls such as links. Existing modeling approaches for describing RESTful APIs expose low-level HTTP details that help developers construct individual requests and parse the corresponding responses. However, very little attention has been given to high-level modeling of RESTful conversations, which abstracts the structure of multiple HTTP interactions. To address such issue in this paper we introduce an extension of the notation used in BPMN choreography diagrams. Its purpose is to represent concisely all possible interaction sequences in a given RESTful conversation.},
	keywords = {BPMN Choreography, REST, RESTful conversation},
	author = {Cesare Pautasso and Ana Ivanchikj and Silvia Schreier}
}
@inproceedings {tcc:2014:wsrest,
	title = {Atomic Distributed Transactions: a RESTful Design},
	year = {2014},
	month = {April},
	publisher = {ACM},
	address = {Seoul, Korea},
	abstract = {The REST architectural style supports the reliable interaction of clients with a single server. However, no guarantees can be made for more complex interactions which require to atomically transfer state among resources distributed across multiple servers. In this paper we describe a lightweight design for transactional composition of RESTful services. The approach -- based on the Try-Cancel/Confirm (TCC) pattern -- does not require any extension to the HTTP protocol. The design assumes that resources are designed to comply with the TCC pattern and ensures that the resources involved in the transaction are not aware of it. It delegates the responsability of achieving the atomicity of the transaction to a coordinator which exposes a RESTful API.},
	keywords = {atomic transactions, REST, TCC},
	author = {Guy Pardon and Cesare Pautasso}
}
@book {rest:2014,
	title = {REST: Advanced Research Topics and Practical Applications},
	year = {2014},
	pages = {1-214},
	publisher = {Springer},
	organization = {Springer},
	keywords = {REST},
	isbn = {978-1-4614-9298-6},
	url = {http://ws-rest.org/book/2/},
	editor = {Cesare Pautasso and Erik Wilde and Rosa Alarc{\'o}n}
}
@inproceedings {lisa:wsrest2014,
	title = {A RESTful API for Controlling Dynamic Streaming Topologies},
	year = {2014},
	month = {April},
	address = {Seoul, Korea},
	abstract = {Streaming applications have become more and more dynamic and heterogeneous thanks to new technologies which enable platforms like microcontrollers and Web browsers to be able to host part of a streaming topology. 
A dynamic heterogeneous streaming application should support load balancing and fault tolerance while being capable of adapting and rearranging topologies to user needs at runtime. 
In this paper we present a REST API to control dynamic heterogeneous streaming applications. By means of resources, their uniform interface and hypermedia we show how it is possible to monitor, change and adapt the deployment configuration of a streaming topology at runtime.},
	keywords = {REST, streaming},
	author = {Masiar Babazadeh and Cesare Pautasso}
}
@article {babazadeh2013www,
	title = {The Atomic Web Browser},
	year = {2013},
	month = {May},
	pages = {217-218},
	address = {Rio de Janeiro, Brazil},
	abstract = {The Atomic Web Browser achieves atomicity for distributed transactions across multiple RESTful APIs. Assuming that the participant APIs feature support for the Try-Confirm/Cancel pattern, the user may navigate with the Atomic Web Browser among multiple Web sites to perform local resource state transitions (e.g., reservations or bookings). Once the user indicates that the navigation has successfully completed, the Atomic Web browser takes care of confirming the local transitions to achieve the atomicity of the global transaction.},
	keywords = {REST, REST transactions, try-confirm-cancel, Web engineering},
	url = {http://dl.acm.org/citation.cfm?id=2487788.2487899},
	author = {Cesare Pautasso and Masiar Babazadeh}
}
@article {rest:tweb:2013,
	title = {Control-Flow Patterns for Decentralized RESTful Service Composition},
	journal = {ACM Transactions on the Web (TWEB)},
	volume = {8},
	year = {2013},
	month = {December},
	pages = {5:1{\textendash}5:30},
	abstract = {The REST architectural style has attracted a lot of interest from industry due to the nonfunctional properties it contributes to Web-based solutions. SOAP/WSDL-based services, on the other hand, provide tools and methodologies that allow the design and development of software supporting complex service arrangements, enabling complex business processes which make use of well-known control-flow patterns. It is not clear if and how such patterns should be modeled, considering RESTful Web services that comply with the statelessness, uniform interface and hypermedia constraints. In this article, we analyze a set of fundamental control-flow patterns in the context of stateless compositions of RESTful services. We propose a means of enabling their implementation using the HTTP protocol and discuss the impact of our design choices according to key REST architectural principles. We hope to shed new light on the design of basic building blocks for RESTful business processes.},
	keywords = {business process management, control flow, control-flow patterns, REST, service composition, Web services},
	issn = {1559-1131},
	doi = {10.1145/2535911},
	url = {http://doi.acm.org/10.1145/2535911},
	author = {Bellido, Jesus and Rosa Alarc{\'o}n and Cesare Pautasso}
}
@inproceedings {restbpm:2013:pesos,
	title = {RESTful Business Process Management in the Cloud},
	year = {2013},
	month = {May},
	address = {San Francisco, CA, USA},
	abstract = {As more and more business processes are migrated into cloud-based runtimes, there is a need to manage their state to provide support for quality attributes such as elasticity, scalability and dependability. In this paper we discuss how the REST architectural style provides a sensible choice to manage and publish service compositions under the Platform as a Service paradigm. We define the design principles of RESTful business process management in the cloud and compare several architectural alternatives to support elastic processes which can be monitored and dynamically adapted to workload changes.},
	keywords = {business process management, cloud computing, REST, RESTful business process management},
	author = {Alessio Gambi and Cesare Pautasso}
}
@inbook {pautasso2013rest,
	title = {RESTful Web Services: Principles, Patterns and Emerging Technologies},
	booktitle = {Web Services Foundations},
	year = {2013},
	pages = {31-51},
	publisher = {Springer},
	organization = {Springer},
	abstract = {RESTful Web services are software services which are published on the Web, taking full advantage and making correct use of the HTTP protocol. This chapter gives an introduction to the REST architectural style and how it can be used to design Web service APIs. We summarize the main design constraints of the REST architectural style and discuss how they impact the design of so-called RESTful Web service APIs. We give examples on how the Web can be seen as a novel kind of software connector, which enables the coordination of distributed, stateful and autonomous software services. We conclude the chapter with a critical overview of a set of emerging technologies which can be used to support the development and operation of RESTful Web services. },
	keywords = {REST, Web services},
	isbn = {978-1-4614-7517-0},
	doi = {10.1007/978-1-4614-7518-7_2},
	url = {http://www.springer.com/computer/database+management+\%26+information+retrieval/book/978-1-4614-7517-0},
	author = {Cesare Pautasso}
}
@book {soawithrest:2013,
	title = {SOA with REST - Principles, Patterns and Constraints for Building Enterprise Solutions with REST},
	series = {The Prentice Hall service technology series},
	year = {2013},
	pages = {I-XXXII, 1-577},
	publisher = {Prentice Hall},
	organization = {Prentice Hall},
	keywords = {REST, service oriented architectures, Web services},
	isbn = {978-0-13-701251-0},
	author = {Thomas Erl and Benjamin Carlyle and Cesare Pautasso and Raj Balasubramanian}
}
@conference {bonetta2012EuroPar,
	title = {Node.Scala: Implicit Parallel Programming for High-Performance Web Services},
	booktitle = {International European Conference on Parallel and Distributed Computing (EuroPar 2012)},
	volume = {7484},
	year = {2012},
	month = {August},
	pages = {626{\textendash}637},
	publisher = {Springer},
	organization = {Springer},
	address = {Rhodes Island, Greece},
	keywords = {Node.JS, REST, Scala, scalability, Web services},
	isbn = {978-3-642-32819-0},
	url = {http://sosoa.inf.unisi.ch/files/sosoa_europar2012.pdf},
	author = {Daniele Bonetta and Danilo Ansaloni and Achille Peternier and Cesare Pautasso and Walter Binder}
}
@article {DBLP:journals/internet/VitvarVP12,
	title = {Programmatic Interfaces for Web Applications},
	journal = {IEEE Internet Computing},
	volume = {16},
	number = {4},
	year = {2012},
	pages = {11-14},
	keywords = {programmable web, REST, Web APIs, Web services},
	doi = {http://doi.ieeecomputersociety.org/10.1109/MIC.2012.86},
	author = {Tomas Vitvar and Steve Vinoski and Cesare Pautasso}
}
@conference {s:2012:ppopp,
	title = {S: a scripting language for high-performance RESTful web services},
	booktitle = {17th ACM SIGPLAN symposium on Principles and Practice of Parallel Programming (PPoPP 2012)},
	year = {2012},
	month = {February},
	pages = {97{\textendash}106},
	publisher = {ACM},
	organization = {ACM},
	address = {New Orleans, USA},
	abstract = {There is an urgent need for novel programming abstractions to leverage the parallelism in modern multicore machines. We introduce S, a new domain-specific language targeting the server-side scripting of high-performance RESTful Web services. S promotes an innovative programming model based on explicit (control-flow) and implicit (process-level) parallelism control, allowing the service developer to specify which portions of the control-flow should be executed in parallel. For each service, the choice of the best level of parallelism is left to the runtime system. We assess performance and scalability by implementing two non-trivial composite Web services in S. Experiments show that S-based Web services can handle thousands of concurrent client requests on a modern multicore machine.},
	keywords = {REST, scripting, Web service composition},
	isbn = {978-1-4503-1160-1},
	doi = {10.1145/2145816.2145829},
	author = {Daniele Bonetta and Achille Peternier and Cesare Pautasso and Walter Binder}
}
@proceedings {wsrest2012,
	title = {Third International Workshop on RESTful Design (WS-REST 2012)},
	year = {2012},
	month = {March},
	publisher = {ACM},
	address = {Lyon, France},
	keywords = {proceedings, REST},
	isbn = {978-1-4503-1190-8},
	doi = {10.1145/2307819.2307821},
	url = {http://dl.acm.org/citation.cfm?id=2307819},
	editor = {Rosa Alarc{\'o}n and Cesare Pautasso and Erik Wilde}
}
@conference {5959776,
	title = {An Architectural Style for Liquid Web Services},
	booktitle = {9th Working IEEE/IFIP Conference on Software Architecture (WICSA 2011)},
	year = {2011},
	month = {June},
	pages = {232-241},
	address = {Boulder, CO, USA},
	abstract = {Just as liquids adapt their shape to the one of their container, liquid architectures feature a high degree of adaptability so that they can provide scalability to applications as they are executed on a wide variety of heterogeneous deployment environments. In this paper we enumerate the properties to be guaranteed by so-called liquid service-oriented architectures and define a set of design constraints that make up a novel architectural style for liquid architectures. These constraints drive the careful construction of a pattern, the Restful Actor (Reactor), which enables to deliver the required scalability by means of replication of its constituent parts. Reactors feature a Restful Web service interface and a composable architecture which is capable of delivering scalability and high performance in a way that is independent from the chosen deployment infrastructure. We discuss how the Reactor can be deployed to run on distributed (shared-nothing) execution environments typical of virtualized Cloud computing environments as well as on modern multicore processors with shared memory architectures.},
	keywords = {architectural styles, cloud computing, design constraints, liquid service oriented architectures, liquid Web services, multicores, patterns, performance, REST, RESTful actor, RESTful Web service interface, scalability, shared memory architectures, virtualized cloud computing environments, Web services},
	doi = {10.1109/WICSA.2011.38},
	author = {Daniele Bonetta and Cesare Pautasso}
}
@conference {rest:bpmn2011,
	title = {BPMN for REST},
	booktitle = {Third International Business Process Modeling Notation Workshop (BPMN 2011)},
	year = {2011},
	month = {November},
	pages = {74-87},
	address = {Lucerne, Switzerland},
	abstract = {The Representational State Transfer (REST) architectural style has seen substantial growth and adoption for the design of modern Resource-Oriented Architectures. However, the impact of fundamental constraints such as stateful resources, stateless interactions, and the uniform interface have had only limited uptake and impact in the Business Process Modeling (BPM) community in general, and in the standardization activities revolving around the BPMN notation. In this paper we propose a simple and minimal extension of the BPMN 2.0 notation to provide first-class support for the concept of resource. We show several examples of how the extended notation can be used to externalize the state of a process as a resource, as well as to describe process-driven composition of resources.},
	keywords = {business process modeling notation, REST, RESTful business process management},
	doi = {10.1007/978-3-642-25160-3_6},
	author = {Cesare Pautasso}
}
@inbook {DBLP:books/sp/wilde2011/PautassoW11,
	title = {Introduction to REST: From Research to Practice},
	booktitle = {REST: From Research to Practice},
	year = {2011},
	pages = {1-18},
	publisher = {Springer},
	organization = {Springer},
	chapter = {1},
	keywords = {REST},
	doi = {10.1007/978-1-4419-8303-9_0},
	url = {http://ws-rest.org/book/},
	author = {Cesare Pautasso and Erik Wilde}
}
@conference {rest:bpm:icsoc2011,
	title = {Push-Enabling RESTful Business Processes},
	booktitle = {9th International Conference on Service-Oriented Computing (ICSOC 2011)},
	volume = {7084},
	year = {2011},
	month = {December},
	pages = {32-46},
	publisher = {Springer},
	organization = {Springer},
	address = {Paphos, Cyprus},
	abstract = {Representational State Transfer (REST) as an architectural style for service design has seen substantial uptake in the past years. However, some areas such as Business Process Modeling (BPM) and push services so far have not been addressed in the context of REST principles. In this work, we look at how both BPM and push can be combined so that business processes can be modeled and observed in a RESTful way. Based on this approach, clients can subscribe to be notified when certain states in a business process are reached. Our goal is to design an architecture that brings REST{\textquoteright}s claims of loose coupling and good scalability to the area of BPM, and still allow process-driven composition and interaction between resources to be modeled.},
	keywords = {business process management, REST, RESTful business process management},
	doi = {10.1007/978-3-642-25535-9_3},
	author = {Cesare Pautasso and Erik Wilde}
}
@book {rest:2011,
	title = {REST: From Research to Practice},
	year = {2011},
	publisher = {Springer},
	organization = {Springer},
	address = {New York, NY},
	keywords = {REST},
	isbn = {978-1-4419-8302-2},
	doi = {10.1007/978-1-4419-8303-9},
	url = {http://ws-rest.org/book/},
	editor = {Erik Wilde and Cesare Pautasso}
}
@conference {www:wsrest2011,
	title = {Second international workshop on RESTful design (WS-REST 2011)},
	booktitle = {WWW (Companion Volume)},
	year = {2011},
	month = {March},
	pages = {311-312},
	publisher = {ACM},
	organization = {ACM},
	address = {Hyderabad, India},
	keywords = {proceedings, REST},
	isbn = {978-1-4503-0637-9},
	doi = {http://doi.acm.org/10.1145/1963192.1963327},
	author = {Cesare Pautasso and Erik Wilde and Rosa Alarc{\'o}n}
}
@inbook {DBLP:books/sp/wilde2011/PardonP11,
	title = {Towards Distributed Atomic Transactions over RESTful Services},
	booktitle = {REST: From Research to Practice},
	year = {2011},
	pages = {507-524},
	publisher = {Springer},
	organization = {Springer},
	abstract = {There is considerable debate in the REST community whether or not transaction support is needed and possible. This chapter{\textquoteright}s contribution to this debate is threefold: we define a business case for transactions in REST based on the Try-Cancel/Confirm (TCC) pattern; we outline a very light-weight protocol that guarantees atomicity and recovery over distributed REST resources; and we discuss the inherent theoretical limitations of our approach. Our TCC for REST approach minimizes the assumptions made on the individual services that can be part of a transaction and does not require any extension to the HTTP protocol. A very simple but realistic example helps to illustrate the applicability of the approach.},
	keywords = {atomic transactions, REST, RESTful Web service interface, try-confirm-cancel},
	doi = {10.1007/978-1-4419-8303-9_23},
	author = {Guy Pardon and Cesare Pautasso}
}
@conference {jopera:2009:sc,
	title = {Composing RESTful Services with JOpera},
	booktitle = {8th International Conference on Software Composition},
	volume = {5634},
	year = {2009},
	month = {July},
	pages = {142-159},
	publisher = {Springer},
	organization = {Springer},
	address = {Zurich, Switzerland},
	abstract = {The REST architectural style is emerging as an alternative technology platform for the realization of service-oriented architectures. In this paper, we apply the notion of composition to RESTful services and derive a set of language features that are required by composition languages for RESTful services: dynamic late binding, dynamic typing, content-type negotiation, state inspection, and compliance with the uniform interface principle. To show how such requirements can be satisfied by an existing composition language, we include a case-study using the JOpera visual composition language. In it, we present how to build a composite application (DoodleMap) out of some well-known, public and currently existing RESTful service APIs.},
	keywords = {JOpera, REST, Web service composition},
	doi = {10.1007/978-3-642-02655-3_11},
	author = {Cesare Pautasso}
}
@article {DBLP:journals/dke/Pautasso09,
	title = {RESTful Web service composition with BPEL for REST},
	journal = {Data Knowl. Eng.},
	volume = {68},
	number = {9},
	year = {2009},
	month = {September},
	pages = {851-866},
	abstract = {Current Web service technology is evolving towards a simpler approach to define Web service APIs that challenges the assumptions made by existing languages for Web service composition. RESTful Web services introduce a new kind of abstraction, the resource, which does not fit well with the message-oriented paradigm of the Web service description language (WSDL). RESTful Web services are thus hard to compose using the Business Process Execution Language (WS-BPEL), due to its tight coupling to WSDL. The goal of the BPEL for REST extensions presented in this paper is twofold. First, we aim to enable the composition of both RESTful Web services and traditional Web services from within the same process-oriented service composition language. Second, we show how to publish a BPEL process as a RESTful Web service, by exposing selected parts of its execution state using the REST interaction primitives. We include a detailed example on how BPEL for REST can be applied to orchestrate a RESTful e-Commerce scenario and discuss how the proposed extensions affect the architecture of a process execution engine. },
	keywords = {BPEL, REST, Web service composition},
	doi = {http://dx.doi.org/10.1016/j.datak.2009.02.016},
	author = {Cesare Pautasso}
}
@conference {tie:2009:gpc,
	title = {The Tiny Instrument Element},
	booktitle = {4th International Conference on Advances in Grid and Pervasive Computing (GPC 2009)},
	year = {2009},
	month = {May},
	pages = {293-304},
	publisher = {Springer},
	organization = {Springer},
	address = {Geneva, Switzerland},
	abstract = {In the past few years, the idea of extending the Grid to cover also the remote access, control, management of instrument devices has been explored in a few initiatives. Existing tools lack in generality and require advanced specialized computer science knowledge, thus making them difficult to be broadly adopted in the scientific community. In this paper we present a new open source initiative that is designed to overcome these problems. The Tiny Instrument Element project defines a high level architecture for plugging instruments into the Grid and provides the corresponding skeleton implementation. This lightweight approach, as opposed to existing middleware-based solutions, reduces the effort required to Gridify existing instruments. The paper evaluates the proposed abstraction with a case study from a pervasive computing scenario.},
	keywords = {pervasive computing, REST, Web of Things},
	doi = {10.1007/978-3-642-01671-4_27},
	author = {Francesco Lelli and Cesare Pautasso}
}
@conference {restws:2009:www,
	title = {Why is the Web Loosely Coupled?  A Multi-Faceted Metric for Service Design},
	booktitle = {18th World Wide Web Conference (WWW2009)},
	year = {2009},
	month = {April},
	pages = {911-920},
	publisher = {ACM},
	organization = {ACM},
	address = {Madrid, Spain},
	abstract = {Loose coupling is often quoted as a desirable property of systems architectures. One of the main goals of building systems using Web technologies is to achieve loose coupling. However, given the lack of a widely accepted definition of this term, it becomes hard to use coupling as a criterion to evaluate alternative Web technology choices, as all options may exhibit, and claim to provide, some kind of "loose" coupling effects. This paper presents a systematic study of the degree of coupling found in service-oriented systems based on a multi-faceted approach. Thanks to the metric introduced in this paper, coupling is no longer a one-dimensional concept with loose coupling found somewhere in between tight coupling and no coupling. The paper shows how the metric can be applied to real-world examples in order to support and improve the design process of service-oriented systems.},
	keywords = {coupling, REST, RESTful Web service interface},
	doi = {10.1145/1526709.1526832},
	author = {Cesare Pautasso and Erik Wilde}
}
@conference {bpel4rest:2008:bpm,
	title = {BPEL for REST},
	booktitle = {7th International Conference on Business Process Management (BPM08)},
	volume = {5240},
	year = {2008},
	month = {September},
	pages = {278-293},
	publisher = {Springer},
	organization = {Springer},
	address = {Milan, Italy},
	abstract = {Novel trends in Web services technology challenge the assumptions made by current standards for process-based service composition. Most RESTful Web service APIs, which do not rely on the Web service description language (WSDL), cannot easily be composed using the BPEL language. In this paper we propose a lightweight BPEL extension to natively support the composition of RESTful Web services using business processes. We also discuss how to expose the execution state of a business process so that it can be manipulated through REST primitives in a controlled way.},
	keywords = {BPEL, REST, RESTful business process management},
	doi = {10.1007/978-3-540-85758-7_21},
	author = {Cesare Pautasso}
}
@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}
}
