M. Gaedke, M. Grossniklaus, and O. Díaz (Eds.): ICWE 2009, LNCS 5648, pp. 394–409, 2009. © Springer-Verlag Berlin Heidelberg 2009 RESTful Transactions Supported by the Isolation Theorems* Amir Razavi, Alexandros Marinos, Sotiris Moschoyiannis, and Paul Krause Department of Computing, FEPS, University of Surrey, Guildford, Surrey, GU2 7XH, UK {a.razavi,a.marinos,s.moschoyiannis,p.krause}@surrey.ac.uk Abstract. With REST becoming the dominant architectural paradigm for web services in distributed systems, more and more use cases are applied to it, including use cases that require transactional guarantees. We propose a RESTful transaction model that satisfies both the constraints of transactions and those of the REST architectural style. We then apply the isolation theorems to prove the robustness of its properties on a formal level. Keywords: REST, Transactions, Isolation Theorems, Locking. 1 Introduction Representational State Transfer (REST) is a distributed computing architectural style first defined in 1999 by Roy Fielding [7] as an abstraction of the architectural style that had emerged in the World Wide Web. REST focuses on resources identified by names, a fixed number of methods with known semantics to manipulate those resources, hypermedia as a means of traversing the resources and statelessness in the interactions between client and server. REST has gained traction in addressing many common use cases for distributed systems [4],[13]. As is common with disruptive technologies, REST over HTTP is evolving to compete with WS-* in increasingly advanced scenarios. While REST has made great progress, the WS-* stack is currently the only standardized way to perform arbitrary transactions. A RESTful API has to resort to custom solutions of variable quality in order to address this issue. This paper aims to define a RESTful transaction model that is designed to operate over HTTP. We then apply the Isolation Theorem to prove the correctness of the model. In terms of RESTful transactions, various approaches have been proposed. The traditional approach is to simply design a new resource that can be used to trigger the desired transaction on the server side. For example, when transferring funds between bank accounts, this approach proposes creating a ‘transfer’ resource to which new ‘transfers’ can be POSTed. While this approach can be very simple to implement at design time, it ties users to the ability of the developers to predict usage at design time. Furthermore, in scenarios where a large or even infinite variation of transactions and transaction types may take place, it is not reasonable to expect all the corresponding * This work was supported by the EU-FP6 funded project OPAALS Contract No 034824.