Rest Ws

3 REST vs WS-* Comparison
Cesare Pautasso
Faculty of Informatics
University of Lugano, Switzerland
c.pautasso@ieee.org
http://www.pautasso.info
Web Sites (1992)
Web HTML Web

Browser HTTP Server
WS-* Web Services (2000)
SOAP WSDL
Client XML Server
(HTTP)
2009-2010 - Cesare Pautasso, Erik Wilde 56
RESTful Web Services (2007)
PO-XML
RSS/Atom
JSON
WADL
Web
Client
HTTP Server
WS-* Web Services (2000)
SOAP WSDL
Client XML Server
(HTTP)
WS-* Standards Stack

RESTful Web Services Standards Stack
AtomPub
RSS Atom
XML JSON
URI HTTP
MIME SSL/TLS

Is REST really used?
2010 - Cesare Pautasso 60

Is REST really used?
Atom, 2%
Gdata, 1%
XMPP, 0%
JavaScript, 6%
XML-RPC, 2%
SOAP, 17% JSON-RPC, 0%
SMS, 2042 APIs

0%
RSS, 1%
ProgrammableWeb.com
30.6.2010
REST,
71%

Can we really compare WS-* vs. REST?
WS-* REST

Can we really compare WS-* vs. REST?
WS-* REST
Middleware Architectural
Interoperability style for
Standards the Web

How to compare?
REST
WS-* Architectural
style for
Middleware the Web
Interoperability
Standards

Architectural Decisions
Architectural decisions Architectural Decision:
capture the main design Programming Language
issues and the rationale
behind a chosen Architecture Alternatives:
technical solution 1. Java
The choice between 2. C#
REST vs. WS-* is an 3. C++
important architectural 4. C
decision for 5. Eiffel
Web service design 6. Ruby
7.
Architectural decisions
affect one another Rationale

Decision Space Overview

Decision Space Overview
21 Decisions and 64 alternatives

Classified by level of abstraction:
3 Architectural Principles
9 Conceptual Decisions
9 Technology-level Decisions
Decisions help us to measure the

complexity implied by the choice of
REST or WS-*

Architectural Principles
1. Protocol Layering
HTTP = Application-level Protocol (REST)
HTTP = Transport-level Protocol (WS-*)
2. Dealing with Heterogeneity
3. Loose Coupling

2009-2010 - Cesare Pautasso 69
RESTful Web Service Example
Web Server
HTTP Client Database
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

WS-* Service Example
(from REST perspective)
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
Applications should publish Applications get a chance
their data on the Web to interact but they remain
(through URI) outside of the Web
AtomPub JSON POX SOAP (WS-*)
HTTP HTTP HTTP HTTP HTTP

SMTP MQ
GET POST PUT DEL POST
(Many) Resource URI 1 Endpoint URI
Application Application

Coupling Facets
Facets REST WS-*
Discovery Referral Centralized
Identification Global Context-Based
Binding Late Late
Platform Independent Independent
Interaction Asynchronous Asynchronous
Model Self-Describing Shared Model
State Stateless Stateless
Generated Code None/Dynamic Static
Conversation Reflective Explicit
More Info on http://dret.net/netdret/docs/loosely-coupled-www2009/

2009-2010 - Cesare Pautasso - 30.6.2010 74
Coupling Comparison
2009-2010 - Cesare Pautasso - 30.6.2010 75

WS-BPEL Primitives

Dealing with Heterogeneity
Enable Cooperation Enable Integration
Web Applications Enterprise Computing
Picture from Eric Newcomer, IONA

HTTP
CICS
IMS

Heterogeneity
Web Enterprise
Applications Architectures
REST WS-*
2009-2010 - Cesare Pautasso - 30.6.2010 78

Heterogeneity
Web Enterprise
Applications Architectures
REST
Claim: REST can also be successfully used

to design integrated enterprise applications
2009-2010 - Cesare Pautasso - 30.6.2010 79
Enterprise Use Cases
Enterprise
Architectures
CRUD Services
Web-friendly APIs
Mobile Services Real-time Services
Transactional Services
Composite Services
2009-2010 - Cesare Pautasso - 30.6.2010 80
Enterprise Use Cases
Enterprise
Architectures
WS-*
REST
Part of the debate is about how many
enterprise use cases can be covered with
REST as opposed to WS-*
2009-2010 - Cesare Pautasso - 30.6.2010 81
Does REST support X?
Service Description Service Composition
Security Transactions
Asynch Messaging Semantics
Reliable Messaging SLAs
Stateful Services Governance


Managing State
REST provides explicit state SOAP services have implicit state
transitions transitions
Communication is stateless* Servers may maintain
conversation state across
Resources contain data and multiple message exchanges
hyperlinks representing valid Messages contain only data
state transitions (but do not include information
Clients maintain application about valid state transitions)
state correctly by navigating Clients maintain state by guessing
hyperlinks the state machine of the service
Techniques for adding session to Techniques for adding session to
HTTP: SOAP:
Session Headers
Cookies (HTTP Headers) (non standard)
URI Re-writing WS-Resource Framework
Hidden Form Fields (HTTP on top of SOAP on top of
HTTP)
(*) Each client request to the server must contain all information needed to understand the request, without referring to any
stored context on the server. Of course the server stores the state of its resources, shared by all clients.

What about service description?
REST relies on human Client stubs can be built from
readable documentation that WSDL descriptions in most
defines requests URIs and programming languages
responses (XML, JSON) Strong typing
Interacting with the service Each service publishes its
means hours of testing and own interface with different
debugging URIs manually semantics
built as parameter WSDL 1.1 (entire port type
combinations. (Is is it really can be bound to HTTP GET or
that simpler building URIs by HTTP POST or SOAP/HTTP
hand?) POST or other protocols)
Why do we need strongly WSDL 2.0 (more flexible,
typed SOAP messages if both each operation can choose
sides already agree on the whether to use GET or POST)
content?
WADL proposed Nov. 2006
XForms enough?

What about security?
REST security is all about SOAP security extensions
HTTPS (HTTP + SSL/TLS) defined by WS-Security
(from 2004)
Proven track record
(SSL1.0 from 1994) XML Encryption (2002)
HTTP Basic Authentication XML Signature (2001)
(RFC 2617, 1999 Implementations are
RFC 1945, 1996) starting to appear now
Full interoperability moot
Note: These are also Performance?
applicable with REST when
using XML content
Secure, end-to-end
Secure, point to point communication Self-
communication protecting SOAP messages
(Authentication, Integrity (does not require HTTPS)
and Encryption)
What about asynchronous reliable
messaging?
SOAP messages can be
Although HTTP is a transferred using
synchronous protocol, asynchronous transport
it can be used to simulate a protocols and APIs
message queue. (like JMS, MQ, )
WS-Addressing can be used
POST /queue to define transport-
independent endpoint
202 Accepted references
Location: WS-ReliableExchange defines
/queue/message/1230213 a protocol for reliable
message delivery based on
GET /queue/message/1230213 SOAP headers for message
identification and
DELETE /queue/message/1230213 acknowledgement

Measuring Complexity
Why is REST perceived to be simpler?
Architectural Decisions give a
quantitative measure of the complexity
of an architectural design space:
Total number of decisions
For each decision, number of alternative options
For each alternative option, estimate the effort
REST WS-*
Decisions 17 14
Alternatives 27 35
Decisions with 1 or more alternative options

REST WS-*
Decisions 5 12
Alternatives 16 32
Decisions with more than 1 alternative options
REST WS-*
Decisions 17 14
Alternatives 27 35
Decisions with 1 or more alternative options

REST WS-*
Decisions 5 12
Alternatives 16 32
URI Design
Resource Interaction Semantics
Payload Format
Service Description
Service Composition
REST WS-*
Decisions 5 12
Alternatives 16 32
REST WS-*
Decisions 12 2
Decisions with only 1 alternative option

Payload Format
Data Representation Modeling
REST WS-*
Decisions 12 2

Measuring Effort
REST WS-*
Do-it-yourself 5 0
Alternatives
Decisions with only do-it-yourself alternatives
REST WS-*
Decisions 12 2

Measuring Effort
REST WS-*
Do-it-yourself 5 0
Alternatives
Decisions with only do-it-yourself alternatives
Resource Identification
Resource Relationship
Reliability
Transactions
Service Discovery
Freedom of Choice (>1 Alternative)
Freedom from Choice (=1 Alternative)

Comparison Summary
Architectural Decisions measure complexity implied

by alternative technologies
REST simplicity = freedom from choice

5 decisions require to choose among 16 alternatives
12 decisions are already taken (but 5 are do-it-yourself)
WS-* complexity = freedom of choice

12 decisions require to choose among 32 alternatives
2 decisions are already taken (SOAP, WSDL+XSD)

Software Connectors
File Transfer
Shared Data
Procedure Call
Remote Procedure Call
Message Bus
Events
RPC
Call
Remote Procedure Call
Procedure/Function Calls are the easiest to program with.

They take a basic programming language construct and make it
available across the network (Remote Procedure Call) to connect
distributed components
Remote calls are often used within the client/server architectural
style, but call-backs are also used in event-oriented styles for
notifications

Hot Folder
Write
Copy File Transfer
(Hot Folder)
Transferring files does not require
Watch to modify components
A component writes a file, which is
Read
then copied on a different host,
and fed as input into a different
component
The transfers can be batched with
a certain frequency

Shared Database
Create
Read Shared Database
Update Sharing a common database does not

require to modify components, if they all
can support the same schema
Delete Components can communicate by

creating, updating and reading entries in
the database, which can safely handles
the concurrency

Bus
Publish
Subscribe Message Bus
A message bus connects a variable number of components, which

are decoupled from one another.
Components act as message sources by publishing messages into
the bus; Components act as message sinks by subscribing to
message types (or properties based on the actual content)
The bus can route, queue, buffer, transform and deliver messages to
one or more recipients
The enterprise service bus is used to implement the SOA style
4.3.2010
Different software connectors
RPC ESB
WS-*
WWW
REST
Web (RESTful Web services)
Get Put
Delete
Post Web
The Web is the connector used in the REST (Representational State
Transfer) architectural style
Components may reliably transfer state among themselves using the
GET, PUT, DELETE primitives. POST is used for unsafe interactions.
Spring Semester 2010

Software Architecture and Design 103
Tuple Space
In Out
Rd Tuple Space
A tuple space acts like a shared database, but offers a much simpler
set of primitives and persistence guarantees
Components can write tuples into the space (with the Out operation)
or read tuples from it (with the Rd operation).
Components that read tuples can also atomically take them out of
the space (with the In operation)
Extensions for the connector are available that support different
kinds of synchronization, in addition to the basic data flow primitives
Spring Semester 2010
Software Architecture and Design 104
Comparison Conclusion
You should focus on whatever solution gets
the job done and try to avoid being religious
about any specific architectures or
technologies.
WS-* has strengths and weaknesses and will
be highly suitable to some applications and
positively terrible for others.
Likewise with REST.
The decision of which to use depends entirely
on the application requirements and
constraints.
We hope this comparison will help you make
the right choice.
2009-2010 - Cesare Pautasso - 30.6.2010 105

Comparison Conclusion
You should focus on whatever solution gets
the job done and try to avoid being religious
about any specific architectures or
technologies.
WS-* has strengths and weaknesses and will
be highly suitable to some applications and
positively terrible for others.
Likewise with REST.
The decision of which to use depends entirely
on the application requirements and
constraints.
We hope this comparison will help you make
the right choice.

4 RESTful Service Composition
Cesare Pautasso
Faculty of Informatics
University of Lugano, Switzerland
c.pautasso@ieee.org
http://www.pautasso.info
REST Architectural Elements
Client/Server Layered Stateless Communication Cache
Proxy
User Agent Origin Server
Gateway
Connector (HTTP) Cache

Basic Setup
HTTP
Adding Caching
HTTP HTTP
Caching Origin Server User Agent Caching

HTTP
Caching Caching

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

What about composition?
The basic REST design WS-BPEL is the standard
elements do not take Web service composition
language. Business process
composition into account models are used to specify
how a collection of services
HTTP is orchestrated into a
composite service
User Agent Origin Server Can we apply WS-BPEL to
RESTful services?
HTTP Origin Server

User Agent ?
Origin Server
BPEL and WSDL 2.0
WSDL 2.0 HTTP Binding can wrap RESTful Web Services
(WS-BPEL 2.0 does not support WSDL 2.0)

BPEL for REST
Make REST interaction primitives first-class language
constructs of BPEL
BPEL for REST PUT

...
<Put R>
GET
R
<Get R>
... POST
DELETE
R>
<Post R>
<Delete R>
<Delete R>
...

BPEL for REST Resource Block
Dynamically publish resources from BPEL
processes and handle client requests
BPEL for REST PUT
<Resource P>
PUT
<onGet>
<Put R> GET
R
P
<Get S> POST
DELETE
GET </onGet>
<onDelete> PUT
POST
DELETE <Post R>
<Delete S>
GET
S
</onDelete>
</Resource> POST
DELETE

REST Scalability
Cache
Proxy/Gateway
Origin
Client
Clients Server
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

REST 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

REST Composition
Proxy/Gateway Origin
Server
Clients
Composition shifts the attention to the client

which should consume and aggregate from
many servers

REST Composition
Client Composite Origin

RESTful Servers
service
The proxy intermediate element which

aggregates the resources provided by
multiple servers plays the role of a
composite RESTful service
Can/Should we implement it with BPM?
Composite Resources
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST

Composite Resources
The composite resource only aggregates the
state of its component resources
R S
State R State S

Composite Resources
The composite resource augments (or caches)
the state of its component resources
C State C
R S
State R State S

Composite Representations
DELETE
PUT
DELETE
Composite GET
R PUT
Representation
POST
S
C
GET
POST
LinkR
LinkS

Composite Representation
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
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

Doodle Map Example
Composite
Representation
Composite Origin
RESTful Servers
service
Client Origin
Servers
Vote on a meeting place based on its

geographic location

1. Composite Resource
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST

1. Composite Resource
DELETE
GET
C
DELETE
POST PUT
GET
R GET
S
POST

2. Composite Representation
DM DELETE
GET
G
LinkG
GET
C
LinkC DELETE
POST PUT
LinkD
GET
R GET
S
POST

RESTful Composition Example

Example: Doodle Map Mashup
Setup a Doodle with Yahoo! Local search
and visualize the results of the poll on
Google Maps

Doodle Map Mashup Architecture
Web Browser Workflow RESTful
Engine Web Services
RESTful API
APIs
GET
POST
GET
Cesare Pautasso, RESTful Web Service Composition with JOpera,

Proc. of the International Conference on Software Composition
(SC 2009), Zurich, Switzerland, July 2009.
Was it just a mashup?
Mashup
REST
Composition
(It depends on the definition of Mashup)

Moving state around
Read-only vs. Read/Write
DELETE
PUT
GET
C
DELETE DELETE
POST PUT PUT
GET
R GET
S
POST POST

Simply aggregating data (feeds)
Read-only vs. Read/write
GET
C
GET
R GET
S

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
Single-Origin Sandbox
Can you always do this
from a web browser?
Composite
Representation
Composite Origin
RESTful Servers
service
Client Origin
Servers

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

Complementary
Read-Only
Read/Write
UI Mashup
REST API
Composition
Reusable
Situational Service
Sandboxed

Conclusions
RESTful HTTP is good enough to interact
without any extension with process
execution engines and their processes and
tasks published as resources
RESTful Web service composition is
different than mashups, but both can be
built using BPM
If done right, BPM can be a great modeling
tool for Hypermedia-centric service design
(and implementation!)
GET http://www.jopera.org/
References
Roy Fielding, Architectural Styles and the Design of Network-based
Software Architectures, PhD Thesis, University of California, Irvine,
2000
Leonard Richardson, Sam Ruby, RESTful Web Services, OReilly,
May 2007
Jim Webber, Savas Parastatidis, Ian Robinson, REST in Practice:
Hypermedia and Systems Architecture, OReilly, 2010
Subbu Allamaraju, RESTful Web Services Cookbook: Solutions for
Improving Scalability and Simplicity, OReilly, 2010
Stevan Tilkov, HTTP und REST, dpunkt Verlag, 2009,
http://rest-http.info/
2009-2010 - Cesare Pautasso - 30.6.2010 140

Web References
Martin Fowler,
Richardson Maturity Model: steps toward the glory of REST,
http://martinfowler.com/articles/richardsonMaturityModel.html
My Constantly Updated Feed or REST-related material:
http://delicious.com/cesare.pautasso/rest
This week in REST
http://thisweekinrest.wordpress.com/
2009-2010 - Cesare Pautasso - 30.6.2010 141

Self-References
Cesare Pautasso, Olaf Zimmermann, Frank 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.
Cesare Pautasso and Erik Wilde. Why is the Web Loosely Coupled? A Multi-
Faceted Metric for Service Design, Proc of the 18th International World
Wide Web Conference (WWW2009), Madrid, Spain, April 2009.
Cesare Pautasso, BPEL for REST, Proc. of the 6th International Conference
on Business Process Management (BPM 2008), Milan, Italy, September
2008.
Cesare Pautasso, RESTful Web Service Composition with JOpera, Proc. Of
the International Conference on Software Composition (SC 2009), Zurich,
Switzerland, July 2009.
Cesare Pautasso, Gustavo Alonso: From Web Service Composition to
Megaprogramming In: Proceedings of the 5th VLDB Workshop on
Technologies for E-Services (TES-04), Toronto, Canada, August 2004
Thomas Erl, Raj Balasubramanians, Cesare Pautasso, Benjamin Carlyle,
SOA with REST, Prentice Hall, end of 2010
2009-2010 - Cesare Pautasso - 30.6.2010 142
Leonard Richardson, Thomas Erl, Raj Balasubramanians,
Sam Ruby, Cesare Pautasso, Benjamin Carlyle,
RESTful Web Services, SOA with REST,
OReilly, May 2007 Prentice Hall, end of 2010
2009-2010 - Cesare Pautasso - 30.6.2010 143

Abstract Submission: Friday, July
2009-2010 - Cesare Pautasso - 30.6.2010
16, 2010 144

Rest Ws

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rest Ws

Загружено:

Авторское право:

Доступные форматы

3 REST vs WS-* Comparison

Web HTML Web

WS-* Web Services (2000)

WS-* Web Services (2000)

2009-2010 - Cesare Pautasso, Erik Wilde 58

2009-2010 - Cesare Pautasso, Erik Wilde 59

2010 - Cesare Pautasso 60

SMS, 2042 APIs

2010 - Cesare Pautasso 61

2009-2010 - Cesare Pautasso, Erik Wilde 62

2009-2010 - Cesare Pautasso, Erik Wilde 63

2009-2010 - Cesare Pautasso, Erik Wilde 64

2009-2010 - Cesare Pautasso, Erik Wilde 65

2009-2010 - Cesare Pautasso, Erik Wilde 66

21 Decisions and 64 alternatives

Decisions help us to measure the

2009-2010 - Cesare Pautasso, Erik Wilde 67

2009-2010 - Cesare Pautasso, Erik Wilde 68

POST /order INSERT

PUT /order/612 UPDATE orders

2009-2010 - Cesare Pautasso, Erik Wilde 70

2009-2010 - Cesare Pautasso, Erik Wilde 71

AtomPub JSON POX SOAP (WS-*)

HTTP HTTP HTTP HTTP HTTP

(Many) Resource URI 1 Endpoint URI

2009-2010 - Cesare Pautasso, Erik Wilde 72

More Info on http://dret.net/netdret/docs/loosely-coupled-www2009/

2009-2010 - Cesare Pautasso - 30.6.2010 75

2010 - Cesare Pautasso 76

Picture from Eric Newcomer, IONA

2009-2010 - Cesare Pautasso, Erik Wilde 77

2009-2010 - Cesare Pautasso - 30.6.2010 78

Claim: REST can also be successfully used

2010 - Cesare Pautasso 82

2009-2010 - Cesare Pautasso, Erik Wilde 83

2009-2010 - Cesare Pautasso, Erik Wilde 84

2009-2010 - Cesare Pautasso, Erik Wilde 86

Decisions with 1 or more alternative options

Decisions with more than 1 alternative options

Decisions with 1 or more alternative options

Decisions with more than 1 alternative options

Decisions with more than 1 alternative options

Decisions with only 1 alternative option

2009-2010 - Cesare Pautasso, Erik Wilde 90

Decisions with only 1 alternative option

2009-2010 - Cesare Pautasso, Erik Wilde 91

Decisions with only do-it-yourself alternatives

Decisions with only 1 alternative option

2009-2010 - Cesare Pautasso, Erik Wilde 92

Decisions with only do-it-yourself alternatives

2009-2010 - Cesare Pautasso, Erik Wilde 94

Architectural Decisions measure complexity implied

REST simplicity = freedom from choice

WS-* complexity = freedom of choice

2009-2010 - Cesare Pautasso, Erik Wilde 95

Procedure/Function Calls are the easiest to program with.

2010 - Cesare Pautasso 98

2010 - Cesare Pautasso 99

Update Sharing a common database does not

Delete Components can communicate by

2010 - Cesare Pautasso 100

A message bus connects a variable number of components, which

Spring Semester 2010