1. Techniques for
Composing REST services
Cesare Pautasso
Faculty of Informatics
University of Lugano, Switzerland
c.pautasso@ieee.org
http://www.pautasso.info

2. Abstract
 Novel trends in Web services technology challenge
the assumptions made by current standards for
process-based service composition. For example,
most existing RESTful Web service APIs (which do
not rely on the Web Service Description Language),
cannot natively be composed using the WS-BPEL
language.
 In this talk we introduce the problem of composing
RESTful services and compare it to Web 2.0 service
mashups. We cover several real-world examples
demonstrating how existing composition languages
can be evolved to cope with REST. We conclude by
showing that the uniform interface and hyper-
linking capabilities of RESTful services provides an
excellent abstraction for exposing in a controlled
way the state of business process as a resource.
©2009 - Cesare Pautasso 2

3. About Cesare Pautasso
 Assistant Professor at the Faculty of Informatics,
University of Lugano, Switzerland (since Sept 2007)
Research Projects:
 SOSOA – Self Organizing Service Oriented Architectures
-
 CLAVOS – Continuous Lifelong Analysis and Verification of
Open Services
 BPEL for REST
 Researcher at IBM Zurich Research Lab (2007)
 Post Doc at ETH Zürich
-
 Software:
JOpera: Process Support for more than Web services
http://www.jopera.org/
 Ph.D. at ETH Zürich, Switzerland (2004)
 Representations:
http://www.pautasso.info/ (Web)
http://twitter.com/pautasso/ (Twitter Feed)
©2009 - Cesare Pautasso 3

4. Why Composition?
 Composition is the key SOA principle
with the goal of enabling
service reuse
©2009 - Cesare Pautasso 4

5. REST and Reuse
 Uniform Interface (Reuse Contract)
 Status Codes (Reuse Metadata)
 Representations (Reuse Media Types)
 Middleware (Reuse caching, security,
load balancing, proxies components)
©2009 - Cesare Pautasso 5

6. REST in one slide
 Web Services expose their
data and functionality trough PUT
resources identified by URI R
 Uniform Interface Principle: GET
Clients interact with resources POST
through a fix set of verbs. DELETE
Example HTTP:
GET (read), POST (create), PUT (update), DELETE
 Multiple representations for the same resource
 Hyperlinks model resource relationships and valid
state transitions for dynamic protocol description
and discovery
©2009 - Cesare Pautasso 6

7. REST and Reuse
 Uniform Interface (Reuse Contract)
 Status Codes (Reuse Metadata)
 Representations (Reuse Media Types)
 Middleware (Reuse caching, security,
load balancing, proxies components)
 Yes, but what about reusing entire RESTful
services?
©2009 - Cesare Pautasso 7

8. RESTful Composition Techniques
1. Defining RESTful service composition
2. Example: DoodleMap
3. What about mashups?
4. BPM and REST
©2009 - Cesare Pautasso 8

9. REST Architectural Elements
Client/Server Layered Stateless Communication Cache
Proxy
User Agent Origin Server
Gateway
Connector (HTTP) Cache
©2009 - Cesare Pautasso 9

10. Basic Setup
HTTP
User Agent Origin Server
Adding Caching
HTTP HTTP
Caching Origin Server User Agent Caching
User Agent Origin Server
HTTP
Caching Caching
User Agent Origin Server
©2009 - Cesare Pautasso 10

11. Proxy or Gateway?
Intermediaries forward (and may translate) requests and responses
HTTP HTTP
Client Proxy Origin Server
A proxy is chosen by the Client (for caching, or access control)
HTTP HTTP
Client Gateway Origin Server
The use of a gateway (or reverse proxy) is imposed by the server
©2009 - Cesare Pautasso 11

12. REST Middleware for Scalability
Cache
Proxy/Gateway Origin
Server
Clients
 One example of REST middleware is to help
with the scalability of a server, which may
need to service a very large number of
clients
©2009 - Cesare Pautasso 12

13. REST Middleware for Composition
Proxy/Gateway Origin
Server
Clients
 Composition shifts the attention to the client
which should consume and aggregate from
many servers
©2009 - Cesare Pautasso 13

14. REST Middleware for Composition
Client Composite Origin
RESTful Servers
service
 The “proxy” intermediate element which
aggregates the resources provided by
multiple servers plays the role of the
composition controller of a composite
RESTful service
©2009 - Cesare Pautasso 14

15. Composite Resources
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST
©2009 - Cesare Pautasso 15

16. Composite Resources
 The composite resource only aggregates the
state of its component resources
C
R S
State R State S
©2009 - Cesare Pautasso 16

17. Composite Resources
 The composite resource augments (or caches)
the state of its component resources
C State C
R S
State R State S
©2009 - Cesare Pautasso 17

18. Enter HATEOAS
 Web Services expose their
data and functionality trough PUT
resources identified by URI R
 Uniform Interface Principle: GET
Clients interact with resources POST
through a fix set of verbs. DELETE
Example HTTP:
GET (read), POST (create), PUT (update), DELETE
 Multiple representations for the same resource
 Hyperlinks model resource relationships and valid
state transitions for dynamic protocol description
and discovery
©2009 - Cesare Pautasso 18

19. Composite Representations
DELETE
PUT
DELETE
Composite GET
R PUT
Representation
POST GET
S
C
POST
LinkR
LinkS
©2009 - Cesare Pautasso 19

20. Composite Representation Pattern
Composite
Representation
Origin
Server
Client Origin
Servers
 A composite representation is interpreted by
the client that follows its hyperlinks and
aggregates the state of the referenced
component resources
©2009 - Cesare Pautasso 20

21. Bringing it all together
Composite
Representation
Composite Origin
RESTful Servers
service
Client Origin
Servers
 A composite representation can be
produced by a composite service too
©2009 - Cesare Pautasso 21

22. Doodle Map Example
Composite
Representation
Composite Origin
RESTful Servers
service
Client Origin
Servers
 Vote on a meeting place based on its
geographic location
©2009 - Cesare Pautasso 22

23. 1. Composite Resource
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST
©2009 - Cesare Pautasso 23

24. 1. Composite Resource
DELETE
GET
C
DELETE
POST PUT
GET
R GET
S
POST
©2009 - Cesare Pautasso 24

25. 2. Composite Representation
DM DELETE
GET
G
LinkG
GET
C
LinkC DELETE
POST PUT
LinkD
GET
R GET
S
POST
©2009 - Cesare Pautasso 25

26. Demo
©2009 - Cesare Pautasso 26

27. Was it just a Mashup?
Mashup
REST
Composition
(It depends on the definition of Mashup)
©2009 - Cesare Pautasso 27

28. Moving state around
 Read-only vs. Read/Write
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST
©2009 - Cesare Pautasso 28

29. Simply aggregating data (feeds)
 Read-only vs. Read/write
GET
C
GET
R GET
S
©2009 - Cesare Pautasso 29

30. Is your composition reusable?
 UI vs. API Composition
Composite
API
Representation
Composite Origin
RESTful Servers
UI
service
 Reusable
Client Origin services vs.
Servers Reusable
Widgets
©2009 - Cesare Pautasso 30

31. Single-Origin Sandbox
 Can you always do this
from a web browser?
Composite
Representation
Composite Origin
RESTful Servers
service
Client Origin
Servers
©2009 - Cesare Pautasso 31

32. Single-Origin Sandbox
 Security Policies on the client may not
always allow it to aggregate data from
multiple different sources
Composite
Representation
Composite N Origin
RESTful Servers
service
Client 1 Origin Server
©2009 - Cesare Pautasso 32

33. Complementary
Read-Only
Read/Write
UI Mashup
REST API
Composition
Reusable
Situational Service
Sandboxed
©2009 - Cesare Pautasso 33

34. RESTful Composition Techniques
1. Defining RESTful service composition
2. Example: DoodleMap
3. What about mashups?
4. BPM and REST
©2009 - Cesare Pautasso 34

35. Web Service Composition Today
The WS-BPEL process
model is layered on top of WS-BPEL 2.0
the service model defined
by WSDL 1.1. […] WSDL 1.1
Both the process and its
partners are exposed as
WSDL services
[BPEL 2.0 Standard, Section 3]
©2009 - Cesare Pautasso 35

36. RESTful Web Services APIs…
WSDL 1.1
…do not
use
WSDL
1.1
©2009 - Cesare Pautasso 36

37. BPEL/WSDL 2.0
WSDL 2.0 HTTP Binding can wrap RESTful Web Services
(WS-BPEL 2.0 does not support WSDL 2.0)
BPEL WSDL 2.0 PUT
Operations
...
Op_1
<Invoke Op_1> Op_2
Op_3 GET
R
<Invoke Op_2> Op_4
... HTTP Binding POST
DELETE
<Invoke Op_3> Op URI Method
Op_1 R PUT
PUT
<Invoke Op_4> Op_2 R GET
GET
Op_3 R POST
POST
... Op_4 R DELETE
DELETE
©2009 - Cesare Pautasso 37

38. BPM RESTful
Workflow Web Service
Languages Composition
©2009 - Cesare Pautasso 38

39. Solutions
BPM RESTful
Workflow Web Service
1. Abstract Workflow Languages Composition
 Service invocation technology does not matter
2. Concrete Workflow
 Expose service invocation BPM RESTful
Workflow Web Service
LanguagesComposition
technologies as explicit constructs
in the workflow language
3. RESTful Workflow
BPM
RESTful
 Workflow as one kind of resource Workflow
Web Service
Languages
Composition
exposed by a RESTful service
©2009 - Cesare Pautasso 39

40. BPEL/WSDL 2.0
WSDL 2.0 HTTP Binding can wrap RESTful Web Services
(WS-BPEL 2.0 does not support WSDL 2.0)
BPEL WSDL 2.0 PUT
Operations
...
Op_1
<Invoke Op_1> Op_2
Op_3 GET
R
<Invoke Op_2> Op_4
... HTTP Binding POST
DELETE
<Invoke Op_3> Op URI Method
Op_1 R PUT
PUT
<Invoke Op_4> Op_2 R GET
GET
Op_3 R POST
POST
... Op_4 R DELETE
DELETE
©2009 - Cesare Pautasso 40

41. BPEL for REST
Make REST interaction primitives first-class language
constructs
BPEL for REST PUT
...
<Put R>
GET
R
<Get R>
... POST
DELETE
R>
<Post R>
<Delete R>
<Delete R>
...
©2009 - Cesare Pautasso 41

42. BPEL for REST
 Dynamically publish resources from BPEL
processes and handle client requests
BPEL for REST PUT
<Resource P>
PUT
<onGet>
<Put R> GET
R
<Get S> POST
GET
P </onGet>
DELETE
<onDelete> PUT
POST
DELETE <Post R>
<Delete S>
GET
S
</onDelete>
</Resource> POST
DELETE
©2009 - Cesare Pautasso 42

43. RESTful Workflows
PUT P
GET
R
POST
DELETE
Use the resource interface
abstraction to publish
the state of the workflow
©2009 - Cesare Pautasso 43

44. DoodleMap as RESTful workflow
©2009 - Cesare Pautasso 44

45. Conclusion
 Applying the SOA composition principle to
REST gives interesting results
 Thanks to hyperlinks, REST brings a new
(more dynamic and loosely coupled)
twist to SOA composition
 Composing RESTful services helps to build
mashups, but is different
 A RESTful API is the perfect abstraction for
publishing the state of a workflow
©2009 - Cesare Pautasso 45

46. References
 R. Fielding, Architectural Styles and the Design of Network-
based Software Architectures, PhD Thesis,
University of California, Irvine, 2000
 C. Pautasso, O. Zimmermann, F. Leymann, RESTful Web
Services vs. Big Web Services: Making the Right Architectural
Decision, Proc. of the 17th International World Wide Web
Conference (WWW2008), Bejing, China, April 2008
 C. Pautasso, BPEL for REST, Proc. of the 7th International
Conference on Business Process Management
(BPM 2008), Milano, Italy, September 2008
 C. Pautasso, Composing RESTful Services with JOpera,
In: Proc. of the International Conference on Software
Composition (SC2009), July 2009, Zurich, Switzerland.
© 46

47. Raj Balasubramanian,
Benjamin Carlyle,
Thomas Erl,
Cesare Pautasso,
SOA with REST,
Prentice Hall,
to appear in 2010
©2009 - Cesare Pautasso 47