SOA with REST

SOA with REST

Prof. Cesare Pautasso
Faculty of Informatics
University of Lugano, Switzerland
Lugano

c.pautasso@ieee.org
http://www.pautasso.info
htt // t i f
@pautasso

About Cesare Pautasso
• Assistant Professor at the Faculty of Informatics,
University of Lugano, Switzerland
y g
• Research Projects:
• SOSOA – Self-Organizing Service Oriented Architectures
• CLAVOS – Continuous Lifelong Analysis and Verification
of Open Services
• BPEL for REST, RESTful Atomic Transactions with TCC
• SAW - Software Architecture Warehouse
• Researcher at IBM Zurich Research Lab (2007)
• Post-Doc at ETH Zürich
• Software: http://www.jopera.org/
JOpera: Process Support for more than Web services
• Ph.D. at ETH Zürich, S t e a d (2004)
ü c , Switzerland ( 00 )
• Laurea Politecnico di Milano (2000)
• Representations:
http://www.pautasso.info/
http://www pautasso info/ (Web)
http://twitter.com/pautasso/ (Twitter Feed)
©2011 Cesare Pautasso 2

Outline
 REST vs. WS-*
 Architectural Styles
 SOA Quality Attributes
 What is REST?
 The Web as a new Software Connector for SOA
 Example: Tunneling or Publishing on the Web?
 SOA with REST

©2010 - Cesare Pautasso 3

SOA REST


RESTful
Service Web Services
Oriented
Architectures
c tectu es
WS-*
Web Services


WS-* Standards Stack


8

Stat
S e
Management

Messaging
Transacti
ions
Se rity
ecur
WS-* Standards Stack

BPM

Re
eliability
Meta ta
M adat

©2011 - Cesare Pautasso
Int oper lity
tero rabi

RESTful Services Standards

AtomPub

RSS Atom

XML JSON

URI HTTP

MIME SSL/TLS


Service Oriented Architectural Style?

©2010 - R. Peisl, 2006
From Cesare Pautasso 10

SOA Quality Attributes
 Interoperability
 Modifiability
 Integrability
 Reuse


Portability
Reliability
R li bili SOA
 Security
 Efficiency
 Business Flexibility/Agility
 Return on Investment


REST Constraints in one slide
 Web Services expose their
data and functionality trough
y g PUT
resources identified by URI
R
 Uniform Interface: GET
Clients perform stateless POST
interactions with resources DELETE
through a fix set of verbs. Example HTTP:
GET (read), PUT (update), DELETE, POST (catch all),
 Multiple representations for the same resource
 Hyperlinks model resource relationships and valid
state transitions for dynamic protocol description
and discovery

Is REST really used?
Atom, 2%
Gdata, 1%
Gd 1%
XMPP, 0%
JavaScript, 6%
XML‐RPC, 2%
SOAP, 17% JSON‐RPC, 0%

SMS,
SMS 3120 APIs
0%
RSS, 1%
ProgrammableWeb.com
1.4.2011
REST,
71%


Design Methodology for REST
1. Identify resources to be exposed as
services (e.g., yearly risk report, book

DE
catalog,
catalog purchase order, open bugs,
order bugs

ELETE
POST
blog entries, polls and votes)

GET

PUT
2. Model relationships (e.g., containment,
reference,
reference state transitions) between /loan    
resources with hyperlinks that can be
followed to get more details (or perform /balance    
state transitions)
/client
/ li t    
3. Define URIs to address the resources
4. Understand what it means to do a GET, /book    
POST, PUT,
POST PUT DELETE for each resource
(and whether it is allowed or not) /order  ?  
5. Design, document and standardize
resource representations (media types)
6. Implement and deploy on Web server /soap    
7. Test with a Web browser


Design Space
M Representations (Variable)


Simple Doodle API Example Design
1. Resources:

DELE
polls and votes

PO
2.
2 Containment Relationship:

GET
G

OST
PUT
P

ETE
poll /poll    
{id1} /poll/{id}    
vote /p /{ }/
/poll/{id}/vote    
{id4} /poll/{id}/vote/{id}    ?

{id5} 3. URIs embed IDs of “child”
instance resources
4. POST on the container is used to
{id2} create child resources
5. PUT/DELETE for updating and
{id3} removing child resources


Simple Doodle API Example
1. Creating a poll
(transfer the state of a new poll on the Doodle service)
/poll
/poll/090331x
/poll/090331x/vote
p

POST /poll GET /poll/090331x
G / ll/090331
<options>A,B,C</options>
200 OK
201 Created <options>A,B,C</options>
Location: /poll/090331x <votes href=“/vote”/>

2. Reading a poll
(transfer the state of the poll from the Doodle service)
(t f th t t f th ll f th D dl i )

 Participating in a poll by creating a new vote sub-resource
/poll
/poll/090331x
/poll/090331x/vote
/p
/poll/090331x/vote/1
/ / /

POST /poll/090331x/vote GET /poll/090331x
G / ll/090331
<name>C. Pautasso</name>
<choice>B</choice> 200 OK
201 Created <votes><vote id=“1”>
Location:
i <name>C. Pautasso</name>
C P t /
/poll/090331x/vote/1 <choice>B</choice>
</vote></votes>


 Existing votes can be updated (access control headers not shown)
/poll
/poll/090331x
/poll/090331x/vote
/p
/ / /

PUT /poll/090331x/vote/1 GET /poll/090331x
G / ll/090331
<choice>C</choice> 200 OK
200 OK <votes><vote id=“/1”>
C P t /
<choice>C</choice>
</vote></votes>


 Polls can be deleted once a decision has been made
/poll
/poll/090331x
/poll/090331x/vote
/p
/ / /

DELETE /poll/090331x GET /poll/090331x
G / ll/090331

200 OK 404 Not Found


The End to End View

R GET
C
A B
PUT GET

 The resource acts as an communication
medium that allows services to exchange
representations of their state
 This is not equivalent to sending and receiving
messages from a bus

Real Doodle Demo
• Info on the real Doodle API:
http://doodle.com/xsd1/RESTfulDoodle.pdf
• Lightweight demo with Poster Firefox Extension:
http://addons.mozilla.org/en-US/firefox/addon/2691


Software Connectors

File Transfer
Fil T f

Shared Data

Procedure Call
Remote Procedure Call
Message Bus
Events

What is your SOA connector today?

RPC BUS

REST/HTTP


REST as a new connector

RPC BUS
Publish/Subscribe
Call

REST/HTTP

Get/Put/Post/Delete


Richardson Maturity Model
0. HTTP as an RPC Protocol
(
(Tunnel POST+POX or POST+JSON) )
I. Multiple Resource URIs
(Fine Grained
(Fine-Grained Global Addressability)
II. Uniform HTTP Verbs
(Contract Standardization)
III. Hypermedia
(Protocol Discoverability)

 A REST API needs to include levels I, II, III
 Most “RESTful” APIs don’t
RESTful don t

Antipatterns - REST vs. HTTP

REST HTTP

“RPC”
RESTful HTTP

Antipatterns – HTTP as a tunnel
 Tunnel through one HTTP Method
GET / i? th d ddC t
/api?method=addCustomer&name=Pautasso
& P t
GET /api?method=deleteCustomer&id=42
GET /api?method=getCustomerName&id=42
GET /api?method=findCustomers&name=Pautasso*

 E
Everything through GET
hi h h
• Advantage: Easy to test from a Browser address bar
(the “action” is represented in the resource URI)
action
• Problem: GET should only be used for read-only
(
(= idempotent and safe) requests.
p ) q
What happens if you bookmark one of those links?
• Limitation: Requests can only send up to approx. 4KB of data
(414 R Request-URI Too Long)
t URI T L )

Antipatterns – HTTP as a tunnel
 Tunnel through one HTTP Method
 Everything through POST
• Advantage: Can upload/download an arbitrary amount of data
(this is what SOAP or XML-RPC do)
• P bl
Problem: POST is not id
i t idempotent and i unsafe (cannot cache)
t t d is f ( t h )

POST /service/endpoint

<soap:Envelope>
<soap:Body>
<findCustomers>
<name>Pautasso*</name>
</findCustomers>
</soap:Body>
</soap:Envelope>

Web Sites (1992)

Web HTML Web
Browser HTTP Server

WS-* Web Services (2000)

SOAP WSDL
Client XML Server
(HTTP)

RESTful Web Services (2007)

PO-X
RSS/A
JSO
WADL

ON
XML
Atom
Web
Client
HTTP Server

WS-* Web Services (2000)

SOAP WSDL
Client XML Server
(HTTP)

RESTful Web Service Example

Web Server
HTTP Client Database
D t b
Application Server
(Web Browser)

SELECT *
GET /book?ISBN=222 FROM books
WHERE isbn=222

POST /order INSERT
INTO orders
301 Location: /order/612

PUT /order/612 UPDATE orders
WHERE id=612
id 612


WS-* Service Example
(from REST perspective)
(f ti )
Web Server Web Service
HTTP Client
Application Server Implementation
(Stub Object)

POST /soap/endpoint
return getBook(222)

POST /soap/endpoint
return new Order()

POST /soap/endpoint
order.setCustomer(x)


Protocol Layering
“The Web is the universe of “The Web is the universal
globally accessible information” (tunneling) transport for
(Tim Berners Lee) messages
messages”
 Applications should publish  Applications get a chance
their data on the Web to interact but they remain
(through URI) “outside of the Web”
outside Web

AtomPub JSON POX … SOAP (WS )
(WS-*)

HTTP HTTP HTTP HTTP HTTP
SMTP MQ…
MQ
GET POST PUT DEL POST

(Many) Resource URI 1 Endpoint URI

Application
pp Application
pp


Dealing with Heterogeneity
 Enable Cooperation  Enable Integration
 Web Applications  Enterprise Architectures
te p se c tectu es

Picture from Eric Newcom IONA
HTTP

mer,
CICS
IMS


Heterogeneity

Web Enterprise
Applications Architectures

REST WS
WS-*


Heterogeneity

Web Enterprise
Applications Architectures

REST

Claim: REST can also be successfully used
to design integrated enterprise applications
t d i i t t d t i li ti

Enterprise “Use Cases”

Enterprise
E t i
Architectures

CRUD Services
Web-friendly APIs
Real-time Services
Mobile Services
M bil S i
Transactional Services
Composite Services

Enterprise “Use Cases”

Enterprise
E t i
Architectures
WS
WS-*

REST
Part f th d b t i b t h
P t of the debate is about how many
“enterprise” use cases can be covered with
REST as opposed to WS-*

SOA Quality Attributes & REST Constraints
 Interoperability  Content Negotiation
 Modifiability  Uniform Interface
 Integrability  Statelessness
 Reuse Interactions



Portability
Reliability
Security
SOA
with REST
 Caching
 Global
Addressability
Addressabilit
 Efficiency  Hypermedia
 Business  Middleware
Flexibility/Agility Intermediaries
( o es Gate ays)
(Proxies & Gateways)
 Return on Investment  Lightweight frameworks


41

Stat
S e
it
Management

with REST?
Can you do
Messaging
Transacti
ions
Se rity
ecur
BPM

Re
eliability
Meta ta
M adat

©2010 - Cesare Pautasso
Int oper lity
tero rabi

Business Process Management
Workflow Workflow
Process Model Users/Clients Participants
Act 2 Act 4

Act 1 Act 5 Act 7

Act 3 Act 6

RESTful Workflow Management Engine

PUT

GET
R Adapters Bus

Applications Web
W b
Services
POST
DELETE Databases


BPM with REST

Process Model
Publishing
Act 2 Act 4 R Processes
P
Act 1 Act 5 Act 7
as Resources
Act 3 Act 6

RESTful Workflow Management Engine

RESTful
Service
R R R Composition


REST Transactions: The Problem
PUT
 Persistent
GET
R RESTful Web Service
Storage

POST
DELETE
Backend 1


PUT

S RESTful Web Service Backend 2
GET

POST Database 3
DELETE

Adapted from Stefan Tilkov, Using REST for SOA, QCon SFO 2010

Conclusions
 SOA comes from the business IT domain, while REST comes
from the World Wide Web.
 REST is more at home with HTTP and HTML while SOA is
HTML,
more at home with SOAP and WSDL.
 Some REST advocates see the Web Services stack both as
begin synonymous with SOA and as an invader in the
architecture of the "real" Web. Some SOA advocates see
REST as an unnecessary diversion from ensuring
connectivity between enterprise service bus technologies
supplied by different vendors.
 Despite their different histories, REST and SOA can learn a
lot from each other.
 SOA with REST aims to forge an effective architectural
model both for enterprise computing and for computing on
the World Wide Web that brings the best of both worlds
together

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
C. Pautasso, O Zimmermann F Leymann, vs
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, Sept. 2008
 C. Pautasso, Composing RESTful Services with JOpera,
In: Proc. of the International Conference on Software Composition
(SC2009), July 2009, Zurich, Switzerland.
 C. Pautasso and E. Wilde, Why is the Web Loosely Coupled? A Multi-
Faceted Metric for Service Design, In: Proc. of the 18th International World
Wide Web Conference (WWW2009), Madrid, Spain, April 2009
 G. Pardon, C. Pautasso, Towards Distributed Atomic Transactions over
RESTful S
S f Services, In: REST: From Research to Practice, S
S Springer, 2011
ISBN 978-1-4419-8302-2
© 46

SOA with REST

Raj Balasubramanian,
Benjamin Carlyle
Carlyle,
Thomas Erl,
Cesare Pautasso,
SOA with REST,
ith REST
Prentice Hall,
to appear in 2011
pp


http://ecows2011.inf.usi.ch/ http://ws-rest.org/book/
p // g/ /

SOA with REST
Prof. Cesare Pautasso
Faculty of Informatics
University of Lugano Switzerland
Lugano,

c.pautasso@ieee.org
http://www.pautasso.info
htt // t i f
@pautasso

SOA with REST

More Related Content

Similar to SOA with REST

More from Cesare Pautasso

Recently uploaded

SOA with REST