Service Oriented Architectures for the REST of Us · 2011-04-25 · foundation for so-called...
Transcript of Service Oriented Architectures for the REST of Us · 2011-04-25 · foundation for so-called...
Service Oriented Architectures Service Oriented Architectures for the REST of Us
Cesare PautassoFaculty of Informatics
University of Lugano SwitzerlandUniversity of Lugano, Switzerland
[email protected] // t i fhttp://www.pautasso.info
@pautasso
About Cesare Pautasso• Assistant Professor at the Faculty of Informatics,
University of Lugano, Switzerland• Research Projects:• Research Projects:
• SOSOA – Self-Organizing Service Oriented Architectures• CLAVOS – Continuous Lifelong Analysis and Verification
of Open Servicesof 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/Software: http://www.jopera.org/JOpera: Process Support for more than Web services
• Ph.D. at ETH Zürich, Switzerland (2004)• Laurea Politecnico di Milano (2000)• Laurea Politecnico di Milano (2000)• Representations:
http://www.pautasso.info/ (Web) http://twitter com/pautasso/ (Twitter Feed)http://twitter.com/pautasso/ (Twitter Feed)
©2011 - Cesare Pautasso 2
Abstract Recent technology trends in Web services indicate that a
solution eliminating the perceived complexity of the WS-* standard technology stack may be in sight: advocates of standard technology stack may be in sight: advocates of representational state transfer (REST) have come to believe that their ideas explaining why the Internet works
j li bl l i i li i are just as applicable to solving enterprise application integration problems and to radically simplifying the "plumbing" of service-oriented architectures. In this p gtutorial, we give an update on how the REST architectural style has been recently rediscovered to become the foundation for so-called "RESTful Web services " After foundation for so-called RESTful Web services. After introducing REST as a set of design constraints, we will show how these can be used as a guide to the design of RESTf l W b i API hil till d li i g t f RESTful Web service APIs while still delivering most of the qualities required in enterprise-grade service-oriented architectures.
©2011 - Cesare Pautasso 3
Outline Introduction What is REST? RESTful Service Design RESTful Web Services within the Enterprise
©2011 - Cesare Pautasso 4
Outline Introduction SOA without WS-* Architectural Styles for SOA REST and enterprise application integration styles The Web as a software connector The Web as a software connector Is REST being used?
What is REST?What is REST? RESTful Service Design RESTful Web Services within the EnterpriseRESTful Web Services within the Enterprise
©2011 - Cesare Pautasso 5
SOA RESTSOA REST
©2011 - Cesare Pautasso 6
RESTfulWeb ServicesService
OrientedWeb Services
OrientedArchitecturesc tectu es
WS-*Web Services
©2011 - Cesare Pautasso 7
WS-* Standards Stack
©2011 - Cesare Pautasso 8
WS-* Standards Stack
Int ManagementBPMtero M Re
Se
Tra Soper
Meta
eliabi
ecur
nsacti
Statrabi
adat
lity
rity
ions
e
lity
ta
Messaging
©2011 - Cesare Pautasso 9
Int ManagementBPMtero M Re
Se
Tra Soper
Meta
eliabi
ecur
nsacti
Statrabi
adat
lity
rity
ions
e
lity
ta
MessagingCan you do it Can you do it with REST?
©2011 - Cesare Pautasso 10
with REST?
RESTful Services Standards
AtomPub
RSS Atom
AtomPub
XML JSON
RSS Atom
URI HTTP
JSON
MIME SSL/TLS
©2011 - Cesare Pautasso 11
What is REST?1. An architectural style for building loosely coupled
distributed hypermedia systems The Web is an architecture which follows the REST style
When the size and complexity of a system grows, we cannot describe its whole architecture, but we can still know its stylestyle
Context Constraints Quality
©2011 - Cesare Pautasso 12
Service Oriented Architectural Style?
©2011 - Cesare Pautasso 13From R. Peisl, 2006
SOA Quality Attributes
Interoperability ModifiabilityModifiability Integrability Reuse Reuse Portability
R li bili SOA Reliability Security
SOA Efficiency Business Flexibility/AgilityBusiness Flexibility/Agility Return on Investment
©2011 - Cesare Pautasso 14
What is REST?1. An architectural style for building loosely coupled
distributed hypermedia systems The Web is an architecture which follows the REST style
2. The Web used correctly to publish Web services Follow Web standards (URI/HTTP/XML/JSON)
HTTP li ti t l HTTP = application protocol
3 The Web misused to publish Web services 3. The Web misused to publish Web services (As long as you do not use SOAP) For example: Plain-Old-XML (POX) over HTTP For example: Plain-Old-XML (POX) over HTTP HTTP = transport/tunneling protocol
©2011 - Cesare Pautasso 15
Web Sites (1992)
HTMLWeb Web HTTPBrowser Server
WS-* Web Services (2000)
SOAP WSDLServerClient XML
©2011 - Cesare Pautasso 16
(HTTP)
RESTful Web Services (2007)
PO-X
RSS/A
JSO
WADL
Client
XML
Atom
ON
Web WADL
Client HTTP Server
WS-* Web Services (2000)
SOAP WSDLServerClient XML
©2011 - Cesare Pautasso 17
(HTTP)
RESTful Web Service Example
HTTP ClientWeb Server
D t bHTTP Client
(Web Browser)Application Server Database
SELECT *GET /book?ISBN=222
SELECT * FROM books
WHERE isbn=222WHERE isbn=222
POST /order INSERTINSERT INTO orders301 Location: /order/612
PUT /order/612 UPDATE ordersWHERE id=612
©2011 - Cesare Pautasso 18
WHERE id 612
WS-* Service Example (f REST ti )(from REST perspective)
HTTP ClientWeb Server Web Service
HTTP Client
(Stub Object)Application Server Implementation
POST /soap/endpointreturn getBook(222)
POST /soap/endpoint
return getBook(222)
return new Order()
POST /soap/endpoint
return new Order()
POST /soap/endpointorder.setCustomer(x)
©2011 - Cesare Pautasso 19
Application vs. Transport Protocol“The Web is the universe of globally accessible information” (Tim Berners Lee)
“The Web is the universal (tunneling) transport for messages”(Tim Berners Lee)
Applications should publish their data on the Web (through URI)
messages Applications get a chance
to interact but they remain “outside of the Web”(through URI) outside of the Web
SOAP (WS-*)AtomPub JSON POX
HTTPHTTP HTTP HTTP HTTP
SOAP (WS )
MQSMTP
AtomPub JSON …POX
(Many) Resource URI
POST
1 Endpoint URI
GET PUT DEL POST MQ…SMTP
Application
(Many) Resource URI
Application
1 Endpoint URI
©2011 - Cesare Pautasso 20
pp pp
WS Technology Design Space
Many Message Formats
WS-*
REST
Representations
Many Message Formats(XML, JSON, ATOM, HTML, CSV, …)
REST
1 Message Format (SOAP)1 Message Format (SOAP)1 Communication “Endpoint”
Many URIs4 HTTP Verbs(GET, PUT, POST, DELETE)
Many Operations (WSDL)Resources Interface
©2011 - Cesare Pautasso 21
Software Connectors
Fil T f
Shared Data
File Transfer
Shared Data
Procedure Call
Message Bus
Procedure CallRemote Procedure Call
©2011 - Cesare Pautasso 22
Message BusEvents
What is your SOA connector today?
RPC BUS
REST/HTTP
©2011 - Cesare Pautasso 23
REST as a new connector
RPC BUSPublish/Subscribe
Call
REST/HTTP
Get/Put/Post/Delete
©2011 - Cesare Pautasso 24
Is REST really used?
Atom, 2%
Gd 1%Gdata, 1%
JavaScript, 6%XML‐RPC, 2%
XMPP, 0%
JSON‐RPC, 0%
SMS
SOAP, 17%
3120 APIs
RSS, 1%
SMS, 0%
3120 APIs
ProgrammableWeb.com
REST, 1.4.2011
71%
©2011 - Cesare Pautasso 25
Outline Introduction What is REST? REST as a hybrid architectural style Resources and URI
U if I t f Uniform Interface Resource Representations: Beyond XML Hypermedia as the engine of application state Hypermedia as the engine of application state Intermediaries
RESTful Service Designg RESTful Web Services within the Enterprise
©2011 - Cesare Pautasso 26
REST Constraints in one slide Web Services expose their
data and functionality trough PUTy gresources identified by URI
Uniform Interface: R
GETUniform Interface: Clients perform statelessinteractions with resources DELETEPOST
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 Hyperlinks model resource relationships and valid
state transitions for dynamic protocol description and discovery
©2011 - Cesare Pautasso 27
and discovery
URI - Uniform Resource Identifier
Internet Standard for resource naming and identification Internet Standard for resource naming and identification (originally from 1994, revised until 2005)
Examples: http://tools.ietf.org/html/rfc3986
URI Scheme Authority Path
https://www.google.ch/search?q=rest&start=10#1
URI Scheme Authority Path
REST d t d t th f “ i ” URI
Query Fragment
REST does not advocate the use of “nice” URIs In most HTTP stacks URIs cannot have arbitrary length (4Kb) #Fragments are not sent to the server
©2011 - Cesare Pautasso 28
#Fragments are not sent to the server
Uniform Interface Constraint
HTTP SAFEIDEM
POTENTPOTENTPOST Create a
sub resource NO NO
GET Retrieve the current state of the resource YES YES
PUTInitialize or update
the state of a resource NO YESresource
at the given URI
DELETEClear a resource, after the URI is no
longer validNO YES
©2011 - Cesare Pautasso 29
longer valid
Uniform Interface Constraint
CRUD RESTCRUD REST
CREATE POST Create a sub resourceC OS sub resource
READ GET Retrieve the current state of the resourcestate of the resource
UPDATE PUTInitialize or update the
state of a resourceUPDATE PUT state of a resourceat the given URI
Clear a reso rce DELETE DELETE
Clear a resource, after the URI is no
longer valid
©2011 - Cesare Pautasso 30
HTML5 Forms
HTML4/XHTML<form method=“GET|POST”> <form method GET|POST >
HTML5 HTML5<form method=“GET|POST|PUT|DELETE”>
http://www.w3.org/TR/html5/forms.html#attr-fs-method
Breaking News
©2011 - Cesare Pautasso 31
POST vs. GET
GET is a read-only operation. It can be repeated without
ff ti th t t f th affecting the state of the resource (idempotent) and can be cached. can be cached.
Note: this does not mean that the same representation will pbe returned every time.
POST is a read-writeti d h g
Web browsers warn you when refreshing
g g t d operation and may change the state of the resource and provoke side effects on the
a page generated with POST
provoke side effects on the server.
©2011 - Cesare Pautasso 32
POST vs. PUTWhat is the right way of creating resources (initialize their state)?PUT /resource/{id}201 CreatedProblem: How to ensure resource {id} is unique? (R b t d b lti l li t tl )(Resources can be created by multiple clients concurrently)Solution 1: let the client choose a unique id (e.g., GUID)
POST /resource301 Moved Permanently301 Moved PermanentlyLocation: /resource/{id}Solution 2: let the server compute the unique idSolution 2: let the server compute the unique idProblem: Duplicate instances may be created if requests are repeated due to unreliable communication
©2011 - Cesare Pautasso 33
Should all agree on the same format?
Client
?Service
New Client
?
How can services support different consumers which make different assumptions about the messaging format?
New Client
different assumptions about the messaging format? Problem: Service consumers may change their requirements in
a way that is not backwards compatible. A service may have to support both old and new consumers without having to introduce a specific interface for each kind of consumer.
©2011 - Cesare Pautasso 34
Solution: Content Negotiation
Client
Service
New Client
Solution: specific content and data representation formats to be accepted or returned by a service capability is negotiated at
New Client
be accepted or returned by a service capability is negotiated at runtime as part of its invocation. The service contract refers to multiple standardized “media types”.
Benefits: Loose Coupling, Increased Interoperability, Increased Organizational Agility
©2011 - Cesare Pautasso 35
Content Negotiation in HTTPNegotiating the message format does not require to send more
messages (the added flexibility comes for free)GET /resourceGET /resourceAccept: text/html, application/xml,
application/jsonapplication/json1. The client lists the set of understood formats (MIME types)
200 OKContent-Type: application/jsonContent-Type: application/json2. The server chooses the most appropriate one for the reply (status 406 if none can be found)
©2011 - Cesare Pautasso 36
Advanced Content NegotiationQuality factors allow the client to indicate the relative
degree of preference for each representation (or di g )media-range).
Media/Type; q=XIf di t h lit l 0 th t t ith If a media type has a quality value q=0, then content with
this parameter is not acceptable for the client. Accept: text/html text/*; q=0 1Accept: text/html, text/*; q=0.1
The client prefers to receive HTML (but any other text format will do with lower priority)p y)
Accept: application/xhtml+xml; q=0.9, text/html; q=0.5, text/plain; q=0.1The client prefers to receive XHTML, or HTML if this is not available and will use Plain Text as a fall back
©2011 - Cesare Pautasso 37
Forced Content NegotiationThe generic URI supports content negotiationGET /resource
t t t/ht l li ti / l Accept: text/html, application/xml, application/json
The specific URI points to a specific representation format using the postfix (extension) / h lGET /resource.html
GET /resource.xmlGET / jGET /resource.json
Warning: This is a conventional practice not a standardWarning: This is a conventional practice, not a standard.What happens if the resource cannot be represented in the
requested format?
©2011 - Cesare Pautasso 38
Multi-Dimensional Negotiation
Content Negotiation is very flexible and can be performed based on different dimensions (each with a specific pair of HTTP headers).
Request Header Example Values Response HeaderAccept: application/xml,
application/jsonContent-Type:
application/json
Accept-Language: en, fr, de, es Content-Language:
h i 88 9 hAccept-Charset: iso-8859-5, unicode-1-1
Charset parameter fo the Content-Type header
Accept-Encoding: compress, i
Content-Encoding:gzip
©2011 - Cesare Pautasso 39
Hypermedia Problem:
• How to discover the URIs of a potentially infinite and p ydynamically changing set of resources?
Solution:• Resource representations contain links that identify
other resources
RRepresentation
PUT
DELETE
PUT
DELETE
RLink
PUT
DELETE
GETP
S
PUT
R LinkP
LinkS
GETPOST
POST
SGET
POST
R
©2011 - Cesare Pautasso 40
LinkS POSTPOST
Hypermedia and Discovery by Referral/R /S Like service discovery:
Clients can use a
GET /R
Clients can use a service to dynamically lookup and discover other services
Link
200 OKother services
Unlike service discovery:LinkS Unlike service discovery: Any resource can refer
clients to any other
GET /Sresource (decentralized)
Links can be 200 OK
Links can be embedded in any hypermedia
t ti f t
©2011 - Cesare Pautasso 41
representation format
Hypermedia (HATEOAS) In addition to resource discovery, hypermedia is used for:
“Hypermedia as the engine of application state”
Relationships between resources can be dynamically discovered by clients following linksdiscovered by clients following links• No need to hardcode resource identifiers into clients• No need to statically specify resource relationships
Links also describe valid protocol state transitions• The service guides the client in discovering what are the
next possible valid interactionsCli t till d t k th ti f li k t l t Clients still need to know the semantics of link traversal to choose what to do• Am I going to be charged $$ if I follow this link?
©2011 - Cesare Pautasso 42
• Am I going to be charged $$ if I follow this link?
REST Architectural Elements
Client/Server Layered CacheStateless Communication
Proxy
User Agent Origin Server
Gateway
CacheConnector (HTTP)
©2011 - Cesare Pautasso 43
Basic Setup
HTTP
User Agent Origin Server
Adding Caching
Caching Origin Server
HTTP
User Agent Caching
HTTP
CachingUser Agent
Origin Server User Agent CachingOrigin Server
HTTP
CachingUser Agent
CachingOrigin Server
©2011 - Cesare Pautasso 44
User Agent Origin Server
Proxy or Gateway?Intermediaries forward (and may translate) requests and responses
Client ProxyHTTP Origin Server
HTTPClient y g
A proxy is chosen by the Client (for caching, or access control)
Client GatewayHTTP
Origin ServerHTTP
The use of a gateway (or reverse proxy) is imposed by the server
©2011 - Cesare Pautasso 45
Outline Introduction What is REST? RESTful Service Design Design Methodology Design Patterns Design Examples Dealing with state Dealing with state Richardson’s Maturity Model
RESTful Web Services within the Enterprise
©2011 - Cesare Pautasso 46
Design Methodology for REST1. Identify resources to be exposed as
services (e.g., yearly risk report, book catalog purchase order open bugs
DEcatalog, purchase order, open bugs,
blog entries, polls and votes)2. Model relationships (e.g., containment,
reference state transitions) between G
ET
PUT
POST
ELETE
/loan reference, state transitions) between resources with hyperlinks that can be followed to get more details (or perform state transitions)
/loan
/balance
/ li t state transitions)
3. Define URIs to address the resources4. Understand what it means to do a GET,
POST PUT DELETE for each resource
/client
/book POST, PUT, DELETE for each resource (and whether it is allowed or not)
5. Design, document and standardize resource representations (media types)
/order ?
resource representations (media types)6. Implement and deploy on Web server7. Test with a Web browser
/soap
©2011 - Cesare Pautasso 47
Design SpaceM Representations (Variable)
©2011 - Cesare Pautasso 48
Simple Doodle API Example Design1. Resources:
polls and votes2 Containment Relationship:
G P PO
DELE
2. Containment Relationship:
GET
PUT
OST
ETE
/poll poll
/poll/{id}
/poll/{id}/vote
{id1}
vote /p /{ }/
/poll/{id}/vote/{id} ?{id4}
3. URIs embed IDs of “child” instance resources
4. POST on the container is used to
{id5}
create child resources5. PUT/DELETE for updating and
removing child resources
{id2}
{id3}
©2011 - Cesare Pautasso 49
removing child resources{id3}
Simple Doodle API Example1. Creating a poll
(transfer the state of a new poll on the Doodle service)
/poll/poll/090331x/poll/090331x/vote
G / ll/090331
p
POST /poll<options>A,B,C</options>
GET /poll/090331x
200 OK201 CreatedLocation: /poll/090331x
200 OK<options>A,B,C</options><votes href=“/vote”/>
2. Reading a poll (t f th t t f th ll f th D dl i )
©2011 - Cesare Pautasso 50
(transfer the state of the poll from the Doodle service)
Simple Doodle API Example Participating in a poll by creating a new vote sub-resource
/poll/poll/090331x/poll/090331x/vote/poll/090331x/vote/1
G / ll/090331
/p / / /
POST /poll/090331x/vote<name>C. Pautasso</name><choice>B</choice>
GET /poll/090331x
200 OK<choice>B</choice>
201 Createdi
200 OK<options>A,B,C</options><votes><vote id=“1”>
C P t /Location: /poll/090331x/vote/1
<name>C. Pautasso</name><choice>B</choice></vote></votes>
©2011 - Cesare Pautasso 51
Simple Doodle API Example Existing votes can be updated (access control headers not shown)
/poll/poll/090331x/poll/090331x/vote/poll/090331x/vote/1
G / ll/090331
/p / / /
PUT /poll/090331x/vote/1<name>C. Pautasso</name><choice>C</choice>
GET /poll/090331x
200 OK<choice>C</choice>
200 OK
200 OK<options>A,B,C</options><votes><vote id=“/1”>
C P t /<name>C. Pautasso</name><choice>C</choice></vote></votes>
©2011 - Cesare Pautasso 52
Simple Doodle API Example Polls can be deleted once a decision has been made
/poll/poll/090331x/poll/090331x/vote/poll/090331x/vote/1
G / ll/090331
/p / / /
DELETE /poll/090331x
200 OK
GET /poll/090331x
404 Not Found200 OK 404 Not Found
©2011 - Cesare Pautasso 53
The End to End View
RGET
CGET
A BPUT 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
©2011 - Cesare Pautasso 54
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
©2011 - Cesare Pautasso 55
Richardson Maturity Model
0. HTTP as an RPC Protocol (Tunnel POST+POX or POST+JSON)( )
I. Multiple Resource URIs(Fine-Grained Global Addressability)(Fine Grained Global Addressability)
II. Uniform HTTP Verbs(Contract Standardization)(Contract Standardization)
III. Hypermedia(Protocol Discoverability)(Protocol Discoverability)
A REST API needs to include levels I, II, III Most “RESTful” APIs don’t
©2011 - Cesare Pautasso 56
Most RESTful APIs don t
Outline
©2009-2010 - Cesare Pautasso - 30.6.2010 57
Tunneling through one endpoint
ClientProviderEndpoint
/
XX Y Z
A B C/soap
X
Z
Business Entities
Problem: A service with a single endpoint is too coarse-grained when its Problem: A service with a single endpoint is too coarse grained when its operations need to be invoked on its data entities. A client needs to work with two identifiers: a global one for the service and a local one for the entity managed by the service. Entity identifiers cannot be easily reused and shared among multiple services
©2011 - Cesare Pautasso 58
and shared among multiple services
Global addressability
Consumer Provider “Entity” Endpoints
X Z A B CY
Solution: expose each resource entitity as individual “endpoint” of the service they reside in
Benefits: Global addressability of service entities
©2011 - Cesare Pautasso 59
What is a “nice” URI?
http://map search ch/lugano
A RESTful service is much more than just a set of nice URIs
http://map.search.ch/lugano
http://maps.google.com/luganop p g g g
http://maps.google.com/maps?f=q&hl=en&q=lugano,+switzerland&layer=&ie=UTF8&z=12&om=1&iwloc=addr
©2011 - Cesare Pautasso 60
URI Design Guidelines Prefer Nouns to Verbs Keep your URIs short
If ibl f ll
GET /book?isbn=24&action=deleteDELETE /book/24
If possible follow a “positional” parameter-passing scheme for
Note: REST URIs are opaque identifiers that are meant to
algorithmic resource query strings (instead of the key=value&p=v encoding)
de t e s t at a e ea t tobe discovered by following hyperlinks and not constructed by the clientg
Some use URI postfixes to specify the content type
constructed by the client
This may break the b t tispecify the content type
Do not change URIs
abstraction
Warning: URI Templates g Use redirection if you really
need to change them
Warning: URI Templates introduce coupling between client and server
©2011 - Cesare Pautasso 61
URI Templates URI Templates specify how to construct and parse
parametric URIs. On the service they are often used to configure “routing rules”On the service they are often used to configure routing rules On the client they are used to instantiate URIs from local parameters
parameters URI
URI Template URI Templateclient service
D t h d d URI i th li t!
URI parameters
Do not hardcode URIs in the client! Do not hardcode URI templates in the client! Reduce coupling by fetching the URI template from the
©2011 - Cesare Pautasso 62
Reduce coupling by fetching the URI template from the service dynamically and fill them out on the client
URI Template Examples From http://bitworking.org/projects/URI-Templates/
Template: Template:
http://www.myservice.com/order/{oid}/item/{iid}
Example URI:
http://www.myservice.com/order/XYZ/item/12345
Template:
http://www.google.com/search?{-join|&|q,num}
E l URI Example URI:
http://www.google.com/search?q=REST&num=10
©2011 - Cesare Pautasso 63
Media Type Design
A REST API should spend almost all of its descriptive effort in defining the media type(s) gused for representing resources and driving application state, or in defining extended
l ti d/ h t t bl d relation names and/or hypertext-enabled mark-up for existing standard media types.
http://roy gbiv com/untangled/2008/rest apis must be hypertext drivenhttp://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
How to find the best media type? How to find the best media type? Reuse generic media types or invent
custom/specific media types?custom/specific media types? Should you always standardize media types?
©2011 - Cesare Pautasso 64
Media Type Design Trade Off
text/xml(Generic, Reusable, Meaningless)(Generic, Reusable, Meaningless)
application/atom+xmlapplication/atom+xml(Standardized, Reusable, Better Defined)
application/vnd.my.type+xml(Specific, Less Reusable, Meaningful)
RFC4288 defines how to register custom media types. List of existing standard media types:
©2011 - Cesare Pautasso 65
g yphttp://www.iana.org/assignments/media-types/
Media Type Design Hints
Reuse Existing Media Types Do not be afraid of inventing your own, but Do not be afraid of inventing your own, but
then standardize it (internally or externally) and reuse it as much as possiblep
Media Types capture the representation format of your resource information/data y /model and the implied processing model
There is no best media type for a service, yp ,it all depends on what your clients need/support/understand
Warning: Clients are not forced to process the media type as you expect them to
©2011 - Cesare Pautasso 66
yp y p
Exception Handling
100 Continue 500 Internal Server Error
501 Not Implemented
Learn to use HTTP Standard Status Codes
100 Continue 200 OK 201 Created 202 Accepted 203 N A th it ti
400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden
501 Not Implemented 502 Bad Gateway
503 Service Unavailable 504 Gateway Timeout
505 HTTP V i N t S t d203 Non-Authoritative 204 No Content 205 Reset Content 206 Partial Content
403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 h i i i d
505 HTTP Version Not Supported
5xx Server’s fault
300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other
407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone
304 Not Modified 305 Use Proxy 307 Temporary Redirect
411 Length Required 412 Precondition Failed 413 Request Entity Too Large 414 Request-URI Too Long 414 Request URI Too Long 415 Unsupported Media Type 416 Requested Range Not Satisfiable 417 Expectation Failed
4xx Client’s fault
©2011 - Cesare Pautasso 67
Idempotent vs. Unsafe Unsafe requests modify the state of
the server and cannot be repeated without additional (unwanted) effects:
Idempotent requests can be processed multiple times without side effects without additional (unwanted) effects:
Withdraw(200$) //unsafe
Deposit(200$) //unsafe
without side-effects GET /book
PUT /order/x p ( ) //
Unsafe requests require special handling in case of exceptional situations (e g state reconciliation)
DELETE /order/y
If something goes wrong ( d situations (e.g., state reconciliation)
POST /order/x/payment
In some cases the API can be
(server down, server internal error), the request can be simply replayed until
redesigned to use idempotent operations:
B = GetBalance() //safe
the server is back up again Safe requests are
idempotent requests which B = GetBalance() //safe
B = B + 200$ //local
SetBalance(B) //idempotent
idempotent requests which do not modify the state of the server (can be cached)
GET /book
©2011 - Cesare Pautasso 68
( ) // pGET /book
Dealing with Concurrency
Breaking down the API into a set of idempotent req ests
/balance
GET /balanceset of idempotent requests helps to deal with temporary failures.
200 OKETag: 26
failures. But what about if another
client concurrently modifies PUT /balance
ETag: 26
ythe state of the resource we are about to update?
200 OKETag: 27
Do we need to create an explicit /balance/lock
? (P i i ti ETag: 27 resource? (Pessimistic Locking)
Or is there an optimistic
©2011 - Cesare Pautasso 69
Or is there an optimistic solution?
Dealing with Concurrency/balance
GET /balance
PUT /b l200 OKETag: 26
PUT /balanceETag: 26
200 OKETag: 27
PUT /balanceETag: 26
409 Conflict
The 409 status code can be used to inform a client that his
©2011 - Cesare Pautasso 70
request would render the state of the resource inconsistent
Blocking or Non-Blocking? HTTP is a synchronous interaction protocol.
However, it does not need to be blocking.
A Long running request may time out.
/slow
POST /slow The server may answer it with 202 Accepted
providing a URI from which the response can be
retrieved later
202 AcceptedLocation: x
GET /slow/x
retrieved later. Problem: how often should
the client do the polling? the client do the polling? /slow/x could include an
estimate of the finishing 200 OK
204 No Content
©2011 - Cesare Pautasso 71
gtime if not yet completed
204 No Content
Redirection for Smooth Evolution
Stale Reference
Consumer Service EndpointRedirect
Consumer Old Endpoint New Endpoint
Redirect
How can consumers of a RESTful service adapt when service plocations and URIs are restructured?
Problem: Service URIs may change over time for business or technical reasons It may not be possible to replace all technical reasons. It may not be possible to replace all references to old links simultaneously risking to introduce broken links.
Solution: Automatically refer service consumers that access
©2011 - Cesare Pautasso 72
Solution: Automatically refer service consumers that access the old identifier to the current identifier.
Redirection with HTTP/
HTTP natively supports redirection using a
/new/old
GET /old
redirection using a combination of 3xx status codes and
301 Moved PermanentlyLocation: /new
status codes and standard headers: 301 Moved Permanently301 Moved Permanently 307 Temporary Redirect Location: /newURI
GET /new
200 OK
Location: /newURI
200 OK
Tip: Redirection responses can be chained.
©2011 - Cesare Pautasso 73
Warning: do not create redirection loops!
Antipatterns - REST vs. HTTP
REST HTTPREST
“RPC”RESTful HTTP
©2011 - Cesare Pautasso 74
Antipatterns – HTTP as a tunnel Tunnel through one HTTP Method
GET / i? th d ddC t & P tGET /api?method=addCustomer&name=PautassoGET /api?method=deleteCustomer&id=42GET /api?method=getCustomerName&id=42GET /api?method=findCustomers&name=Pautasso*
E hi h h GET Everything through GET• Advantage: Easy to test from a Browser address bar
(the “action” is represented in the resource URI)(the action is represented in the resource URI)• Problem: GET should only be used for read-only
(= idempotent and safe) requests. ( p ) qWhat happens if you bookmark one of those links?
• Limitation: Requests can only send up to approx. 4KB of data (414 R t URI T L )
©2011 - Cesare Pautasso 75
(414 Request-URI Too Long)
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 POST i t id t t d i f ( t h )• Problem: POST is not idempotent and is unsafe (cannot cache)
POST /service/endpoint
<soap:Envelope><soap:Body>
<findCustomers><findCustomers><name>Pautasso*</name>
</findCustomers></soap:Body>
©2011 - Cesare Pautasso 76
</soap:Body></soap:Envelope>
Dealing with Heterogeneity
Enterprise Architectures Web Applications
Enable Cooperation Enable Integrationte p se c tectu esWeb Applications
PPicture from HTTP
CICS
Eric N
ewcom
HTTP
CICSIMS
mer, IO
NA
©2011 - Cesare Pautasso 77
Heterogeneity
EnterpriseWeb EnterpriseArchitectures
WebApplications ArchitecturesApplications
REST WS-*REST WS
©2011 - Cesare Pautasso 78
Heterogeneity
Web EnterpriseWebApplications
EnterpriseArchitecturesApplications Architectures
RESTREST
Claim: REST can also be successfully used t d i i t t d t i li ti
©2011 - Cesare Pautasso 79
to design integrated enterprise applications
Enterprise “Use Cases”
E t iEnterpriseArchitecturesArchitectures
CRUD ServicesCRUD ServicesWeb-friendly APIs
M bil S iReal-time Services
Mobile Services
Composite ServicesTransactional Services
©2011 - Cesare Pautasso 80
Composite Services
Enterprise “Use Cases”
E t iEnterpriseArchitecturesArchitectures
WS-*
RESTWS
P t f th d b t i b t h Part of the debate is about how many “enterprise” use cases can be covered with
©2011 - Cesare Pautasso 81
REST as opposed to WS-*
Outline Introduction What is REST? RESTful Service Design RESTful Web Services within the Enterprise What about service description? What about security?
Wh t b t li bilit ? What about reliability? Composing RESTful Web Services Mashups vs Composite RESTful Web ServicesMashups vs. Composite RESTful Web Services RESTful Business Process Management Transactional RESTful Web Services
©2011 - Cesare Pautasso 82
What about service description?
REST relies on human readable documentation that defines req ests URIs and
Client stubs can be built from WSDL descriptions in most programming lang agesdefines requests URIs and
responses (XML, JSON) Interacting with the service
programming languages Strong typing Each service publishes its
means hours of testing and debugging URIs manually built as parameter
bi i (I i i ll
pown interface with different semantics
WSDL 1 1 (entire port type combinations. (Is is it really that simpler building URIs by hand?)
WSDL 1.1 (entire port type can be bound to HTTP GET or HTTP POST or SOAP/HTTP POST or other protocols)
Why do we need strongly typed SOAP messages if both sides already agree on the
POST or other protocols) WSDL 2.0 (more flexible,
each operation can choose whether to use GET or POST)content?
WADL proposed Nov. 2006 XForms enough?
whether to use GET or POST)
XForms enough?
©2011 - Cesare Pautasso 83
What about security?
REST security is all about HTTPS (HTTP + SSL/TLS)
SOAP security extensions defined by WS-Security HTTPS (HTTP + SSL/TLS)
Proven track record (SSL1.0 from 1994)HTTP B i A h i i
(from 2004) XML Encryption (2002) XML Signature (2001) HTTP Basic Authentication
(RFC 2617, 1999RFC 1945, 1996)
XML Signature (2001) Implementations are
starting to appear now
Note: These are also applicable with REST when
Full interoperability moot Performance?
applicable with REST when using XML content
Secure, end-to-end Secure, point to point
communication (Authentication, Integrity
Secure, end to end communication – Self-protecting SOAP messages (does not require HTTPS)( , g y
and Encryption)(does not require HTTPS)
©2011 - Cesare Pautasso 84
What about asynchronous reliable messaging?
SOAP messages can be Although HTTP is a
synchronous protocol, it can be used to “simulate” a
transferred using asynchronous transport protocols and APIs
message queue.
POST /queue
(like JMS, MQ, …) WS-Addressing can be used
to define transport-POST /queue
202 AcceptedLocation:
pindependent endpoint references
WS-ReliableExchange defines Location: /queue/message/1230213
GET /queue/message/1230213
WS ReliableExchange defines a protocol for reliable message delivery based on SOAP headers for message GET /queue/message/1230213
DELETE /queue/message/1230213
SOAP headers for message identification and acknowledgement
©2011 - Cesare Pautasso 85
Managing State
REST provides explicit state transitions
C i i i l *
SOAP services have implicit state transitions Servers may maintain Communication is stateless*
Resources contain data and hyperlinks representing valid
Servers may maintain conversation state across multiple message exchanges
Messages contain only data state transitions
Clients maintain application state correctly by navigating
g y(but do not include information about valid state transitions)
Clients maintain state by guessing h hi f h ihyperlinks
Techniques for adding session to HTTP:
the state machine of the service Techniques for adding session to
SOAP:S i H d
Cookies (HTTP Headers) URI Re-writing Hidden Form Fields
Session Headers (non standard)
WS-Resource Framework (HTTP on top of SOAP 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
©2011 - Cesare Pautasso 86
( ) Each client request to the server must contain all information needed to understand the request, without referring to anystored context on the server. Of course the server stores the state of its resources, shared by all clients.
What about composition?
The basic REST design elements do not take
WS-BPEL is the standard Web service composition elements do not take
composition into account language. Business process models are used to specify how a collection of services is orchestrated into a composite service
Can we apply WS BPEL to User Agent Origin Server
HTTP
Can we apply WS-BPEL to RESTful services?
User Agent Origin Server
Origin ServerHTTP
?
Origin Server
User Agent
©2011 - Cesare Pautasso 87
Origin Server
Business Process Management
Process ModelWorkflow Users/Clients
Workflow Participants
Act 1
Act 2
Act 7Act 5
Act 4Users/Clients Participants
Act 3 Act 6
RESTful Workflow Management Engine
PUT
W bApplications
Adapters BusRGET Web
ServicesApplications
DatabasesDELETEPOST
©2011 - Cesare Pautasso 88
Databases
BPM with REST
Process Model
RPublishingP
Act 1
Act 2
Act 7Act 5
Act 4 R Processesas Resources
Act 3 Act 6
RESTful Workflow Management Engine
RESTfulServiceR ServiceCompositionRR
©2011 - Cesare Pautasso 89
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)(WS-BPEL 2.0 does not support WSDL 2.0)
©2011 - Cesare Pautasso 90
BPEL for REST
Make REST interaction primitives first-class language constructs of BPEL
BPEL for REST PUT
RGET
...
<Put R><Put R>
DELETE
GET
POST<Get R>
...
<Get R>
<Post R>
<Delete R>
<Post R>
<Delete R>
©2011 - Cesare Pautasso 91
...
BPEL for REST – Resource Block Dynamically publish resources from BPEL
processes and handle client requestsprocesses and handle client requests
BPEL for REST
PUT<Resource P>
<onGet>
<Put R>RGETPUT
<Get S>
</onGet>
l
DELETEPOST
PUT
PGET
<Post R>
<Delete S>
<onDelete>
S
PUTDELETEPOST
</onDelete>
</Resource>
S
DELETE
GET
POST
©2011 - Cesare Pautasso 92
REST Scalability
Cache
Origin Server
Clients
Proxy/Gateway
Clients
O l f REST iddl i t h l One example of REST middleware is to help with the scalability of a server, which may
need to service a very large number of need to service a very large number of clients
©2011 - Cesare Pautasso 94
REST Composition
Origin Server
Clients
Proxy/Gateway
Clients
C iti hift th tt ti t th li t Composition shifts the attention to the client which should consume and aggregate from
many serversmany servers
©2011 - Cesare Pautasso 95
REST Composition
CompositeServersOrigin Client Composite
RESTfulservice
Th “ ” i t di t l t hi h
se ce
The “proxy” intermediate element which aggregates the resources provided by
multiple servers plays the role of a multiple servers plays the role of a composite RESTful service
Can/Should we implement it with BPM?©2011 - Cesare Pautasso 96
Can/Should we implement it with BPM?
Composite Resources
PUT
DELETE
DELETEGETC
PUT
DELETEGET
POST PUT
DELETE
GETR
GETS
POST POST
©2011 - Cesare Pautasso 97
Composite Resources The composite resource only aggregates the
state of its component resources
C
R SState
RState
S
©2011 - Cesare Pautasso 98
Composite Resources The composite resource augments (or caches)
the state of its component resources
StateC
CC
R SState
RState
S
©2011 - Cesare Pautasso 99
Composite Representations
PUT
DELETE
PUT
PUT
DELETE
GETR
C it GET
GETPOST
CS
Composite Representation
GETPOST
POSTC
i kLinkR
LinkLinkS
©2011 - Cesare Pautasso 100
Composite Representation
CompositeRepresentationRepresentation
OriginServerServer
Origin Client gServers
A composite representation is interpreted by A composite representation is interpreted by the client that follows its hyperlinks and aggregates the state of the referenced
©2011 - Cesare Pautasso 101
gg gcomponent resources
Bringing it all together
CompositepRepresentation
Composite OriginpRESTfulservice
Origin Servers
OriginClient Origin Servers
C e
A it t ti b A composite representation can be produced by a composite service too
©2011 - Cesare Pautasso 102
Doodle Map Example
CompositepRepresentation
Composite OriginpRESTfulservice
Origin Servers
OriginClient Origin Servers
C e
V t ti l b d it Vote on a meeting place based on its geographic location
©2011 - Cesare Pautasso 103
1. Composite Resource
PUT
DELETE
DELETEGETC
PUT
DELETEGET
POST PUT
DELETE
GETR
GETS
POST POST
©2011 - Cesare Pautasso 104
1. Composite Resource
DELETE
GETC
GET
POST PUT
DELETE
GETR
GETS
POST
©2011 - Cesare Pautasso 105
2. Composite Representation
GDELETEDM GETG
GETC
DELETE
LinkG
Li kGET
POST PUT
DELETELinkC
Li k
GETR
GETS
LinkD
POST
©2011 - Cesare Pautasso 106
RESTful Composition Example
©2011 - Cesare Pautasso 107
Example: Doodle Map Mashup
Setup a Doodle with Yahoo! Local search fand visualize the results of the poll on
Google Maps
©2011 - Cesare Pautasso 108
Doodle Map Mashup Architecture
Web Browser Workflow RESTfulEngine Web Services
APIsGETfu
l API
GET
POSTRES
TfPOST
GET
ResourcesComposite Composite
©2011 - Cesare Pautasso 109
ResourcesRepresentations
Was it just a mashup?
MashupREST
MashupREST
CompositionComposition
(It d d th d fi iti f M h )©2011 - Cesare Pautasso 110
(It depends on the definition of Mashup)
Moving state around
Read-only vs. Read/Write
PUT
DELETE
DELETEGETC
DELETE
PUT
DELETEGET
POST PUT
DELETE
GETR
GETS
POST POST
©2011 - Cesare Pautasso 111
Simply aggregating data (feeds)
Read-only vs. Read/write
GETC
GET
GETR
GETS
©2011 - Cesare Pautasso 112
Is your composition reusable?
UI vs. API Composition
C itAPI
CompositeRepresentation
C itCompositeRESTfulservice
Origin Servers
UICli t
serviceUI Reusable i Origin
ServersClient services vs.
Reusable Widgets
©2011 - Cesare Pautasso 113
Widgets
Single-Origin Sandbox
Can you always do thisfrom a web browser?from a web browser?
C it
C it
CompositeRepresentation
CompositeRESTfulservice
Origin Servers
Cli t
service
Client Origin Servers
©2011 - Cesare Pautasso 114
Single-Origin Sandbox
Security Policies on the client may not always allow it to aggregate data from always allow it to aggregate data from multiple different sources
C itCompositeRepresentation
C itCompositeRESTfulservice
N Origin Servers
Cli t
service
1 O i i SClient 1 Origin Server
©2011 - Cesare Pautasso 115
Complementary
Read-OnlyRead/WriteRead/Write
Mashup RESTMashup APIUI
RESTCompositionp
SituationalReusable
ServiceServiceSandboxed
©2011 - Cesare Pautasso 116
BPM with REST
Process Model
RPublishingP
Act 1
Act 2
Act 7Act 5
Act 4 R Processesas Resources
Act 3 Act 6
RESTful Workflow Management Engine
RESTfulServiceR ServiceCompositionRR
©2011 - Cesare Pautasso 117
BPM RESTBPM REST Resources/URIs
U if Processes
Uniform Interface
Tasks Control Flow te ace
Representations Control FlowData Flow
Hypermedia…
©2011 - Cesare Pautasso 119
Everything is a resource
/process/X /process/X/1
ProcessProcessInstanceInstance
Task TaskInstanceInstance
/task/Y/task/Y/1
©2011 - Cesare Pautasso 120
Hypermedia
ProcessProcessInstance
/process
Task Task/process/nameGET
TaskInstance
/process/name/instance
GET
/process/name/instance
GET/process/name/instance/taskname
Follow links to discover the processesdeployed as resources
©2011 - Cesare Pautasso 121
deployed as resources
RepresentationsWeb page
with form to starta new process
List of processinput parameters
ContentType:
text/htmlContentType:
application/xml
a new processinstance
p p
/process/nameGET
text/html application/xml
/process/nameGET
ContentType:
t t/ l iContentType:
li ti /jtext/plain application/jsonContentType:
i / lBasic textual Process
image/svg+xmldescriptionof the process
metadatain JSON
©2011 - Cesare Pautasso 122
Uniform Interface and Hypermedia
/processGETList the
deployed Get a form
/process/nameGET
p yprocesses
Get a form describing how
to start the /p /process
Start a new /process/namePOST process
instance Check what
GET /process/name/instanceis the state
of the instance
DELETE /process/name/instance
instance
Clean up
©2011 - Cesare Pautasso 123
Clean up(once it is done)
Starting or Running a new process?
Should the client be kept waiting for the process to run
/process
POST /process
waiting for the process to run until completion?
Clients may want to block until 200 OK Clients may want to block until the whole process has completed its execution
(Process Finished
R l )
©2011 - Cesare Pautasso 124
(or it decides to reply to them)Reply)
Starting or Running a new process?
The client starting a long running process is redirected to
/process
POST /process
running process is redirected to a location x representing the newly started process instance
The process and the client run asynchronously202 Accepted
Location: x
GET /process/x
The client may retrieve the current state of the process i t t ti
Location: x
GET /process/x instance at any time
200 OK
©2011 - Cesare Pautasso 125
Uniform Interface and Hypermedia
/taskGET List the active tasks Get a form
/task/name/instanceGET
active tasks Get a form describing how to perform the / / / p
task
Finish /task/name/instancePOST
Finish the task
GET /task/name/instance Get the finalrepresentation p
of the completed task…
©2011 - Cesare Pautasso 126
POST or PUT?
/taskGET Note:PUT could also be
/task/name/instanceGET
PUT could also be used here
to set the state / / / to set the state (Finished, Failed)
of the task/task/name/instancePOST
GET /task/name/instance
…
©2011 - Cesare Pautasso 127
Example: RESTBucks
128Jim Webber, Savas Parastatidis, Ian Robinson
Simple RESTBucks Example
POST
/rest/restbucks/order/1.0/{id}
/rest/restbucks/order/1.0/ POST
/tasks/restbucks/order/1.0/{id}/payment
GET
/ / / / /{ }/p y
POST
GET
/receipt/{uuid}
©2011 - Cesare Pautasso 129
Simple RESTBucks ExampleHypermedia Centric Service Design done with a business process model R
es
Privsou
vaterces
e Tass sks
©2011 - Cesare Pautasso 130
Instantiating a process
GET /rest/restbucks/order/1.0/
©2011 - Cesare Pautasso 131
Retrieve a form which describes how to instantiate a new process
Instantiating a process
POST /rest/restbucks/order/1.0/
R bl ki Run = blocking (client waits until
Start = non blocking (redirect to URI of
the process replies)
©2011 - Cesare Pautasso 132
(the new instance)
Interacting with a task
GET /task/restbucks/order/1.0/0/payment
©2011 - Cesare Pautasso 133
Interacting with a task
POST /rest/restbucks/order/1.0/0/payment
©2011 - Cesare Pautasso 134
Interacting with a resource
GET /receipt/2fc7f6e2-8b43-4672-a7c4…
©2011 - Cesare Pautasso 135
Interacting with a resource
DELETE /rest/restbucks/order/1.0/0
©2011 - Cesare Pautasso 136
Deleting a process resource
DELETE /rest/restbucks/order/1.0/0
©2011 - Cesare Pautasso 137
Static vs. Dynamic Typing
Myth: RESTful Web services cannot be composed (with BPEL) because they do composed (with BPEL) because they do not give a static contract descriptionR lit RESTf l W b i Reality: RESTful Web services can dynamically negotiate the most
it bl t ti f t ith suitable representation format with their clients Challenge: How to support dynamic
typing and content type negotiation in a yp g yp gBPM composition language?
©2011 - Cesare Pautasso 138
Active Resources
Myth: Processes cannot be mapped to resources because they can change resources because they can change their state (independently of their clients)clients) Reality: REST Resources do not have to
b i “CRUD” i b t b be passive “CRUD” services but can be active and have a life of their own. Challenge: How to best let clients
control an active resource backed up pby a process instance through the uniform interface?
©2011 - Cesare Pautasso 139
uniform interface?
Synchronous vs. Asychronous
Myth: Processes run for a long time and need to interact asynchronously and need to interact asynchronously with their clients. This cannot be done with HTTPwith HTTP. Reality: HTTP supports non blocking
i t ti E h i t i interactions. Each process instance is mapped to a resource URI, which can b d b li h h i be used by clients throughout its lifetime. Challenge: How to let processes send
notifications back to their clients?
©2011 - Cesare Pautasso 140
notifications back to their clients?
BPM with REST
REST resources are a good abstraction to publish processes on the Webto publish processes on the Web RESTful HTTP is good enough to
i t t ith t t i ith interact without any extension with process execution engines and drive th ti f d t k the execution of process and task instances If done right, BPM can be a great
modeling tool for Hypermedia-centric g ypservice design(and implementation!)
©2011 - Cesare Pautasso 141
(and implementation!)
REST Transactions: The Problem
RESTful Web Service Persistent R
PUT RESTful Web Service
StorageRGET
Backend 1DELETEPOST
RESTful Web Service Backend 2SPUT Backend 2
Database 3
SGET
POST Database 3DELETEPOST
©2011 - Cesare Pautasso 142
Adapted from Stefan Tilkov, Using REST for SOA, QCon SFO 2010
Does REST need transactions? If you find yourself in need of a distributed
transaction protocol, then how can you possibly say th t hit t i b d REST? I i l that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of t ti ti h i th li t h t t ll transaction semantics wherein the client has to tell the server how to manage its own resources.
for now I consider "rest transaction" to be an ...for now I consider rest transaction to be an oxymoron.
Roy Fielding, REST discuss, June 9th, 2009
©2011 - Cesare Pautasso 143
Does REST need transactions? The typical conversation thread, real or virtual, about
transactions over HTTP goes something like this ( lid d f b it ) (elided for brevity): "You don't want transactions over HTTP" But I need to organize number of steps into a single unit I But I need to organize number of steps into a single unit I
can deal with easily. "OK, but you don't need transactions over HTTP" But I need the ability to back out changes in multiple
locations safely and consistently. "OK but you can't do transactions over HTTP!" OK, but you can t do transactions over HTTP! Really?
And here the topic usually dies or descends into a p yheated debate.
Mike Amudsen, htt // d /bl / hi /1024
©2011 - Cesare Pautasso 144
http://amundsen.com/blog/archives/1024
Context
RESTful Web Service Persistent R
PUT RESTful Web Service
StorageRGET
Backend 1DELETEPOST
RESTful Web Service Backend 2SPUT Backend 2
Database 3
SGET
POST Database 3DELETEPOST
©2011 - Cesare Pautasso 145
Adapted from Stefan Tilkov, Using REST for SOA, QCon SFO 2010
The problem
PUT
RESTful Web ServiceRGET
Client State transfer
DELETEPOST
SPUTState transfer
RESTful Web ServiceSGET
Thanks to the idempotency of GET/PUT DELETEPOST
©2011 - Cesare Pautasso 146
Thanks to the idempotency of GET/PUT, each individual state transfer is reliable and atomic
The problem
PUT
RESTful Web ServiceRGET
State transfer
DELETEPOSTClient
SPUTState transfer
RESTful Web ServiceSGET
DELETEPOST
©2011 - Cesare Pautasso 147
How to we make both interactions atomic?
Constraints
Interoperability: No changes/extensions to HTTPg
• No additional verbs• No special/custom headers
Loose Coupling:p g REST shifts all the “work” to the client RESTful Web services should remain unaware
h i i i i ithey are participating in a transaction
Si li it Simplicity: Transactions will not be adopted in practice
unless they can be made simple enough
©2011 - Cesare Pautasso 148
unless they can be made simple enough
Assumption: Try-Confirm/Cancel Resource state transitions follow the TCC pattern
CancelCancel
C fiInitialState Reserved
FinalState
Try ConfirmState Reserved
State
StateTimeout
Before they are made permanent state transitions go through an intermediate “reserved” statego through an intermediate reserved statewhich either will be confirmed or canceled by a client within a given timeHi t C l/C fi id t t
©2011 - Cesare Pautasso 149
Hint: Cancel/Confirm are idempotent
Example: Flight Booking Resource
Try POST /booking
Reserve the flightReserve the flight/ g
302 Location: /booking/XURI of the
d t tURI of the
d t tConfirm PUT /booking/X
reserved statereserved state
PUT /booking/X 200
Pay and confirm the flight
Pay and confirm the flight
CancelDELETE /b ki /X Cancel the Cancel the DELETE /booking/X
200
Cancel the reservationCancel the reservation
©2011 - Cesare Pautasso 150
Protocol1. A client interacts with multiple RESTful Web services.
Interactions may lead to state transitions (th i t di t t t i id tifi d b URI k t (the intermediate state is identified by a URI known to the client)
2 Once the client has completed all interactions it uses 2. Once the client has completed all interactions, it uses the URIs identifying the intermediate states to confirm the state transitions (and thus commit the transaction)
Note: If the client stops before step 2, the state transitions will eventually be undone by the services themselves (after a timeout) themselves (after a timeout). As an optimization, the client can use the same URIs to cancel the state transitions (and thus explicitly
©2011 - Cesare Pautasso 151
rollback the transaction).
Simple Example
POST www.swiss.ch/booking302 Location: /booking/11 302 Location: /booking/1
POST www ezyj com/booking
1.POST www.ezyj.com/booking302 Location:/booking/X
PUT www.swiss.ch/booking/1
2 2002.PUT www.ezyj.com/booking/X200
©2011 - Cesare Pautasso 152
200
What if something fails?
POST www.swiss.ch/booking302 Location: /booking/11 Whatever
happens these Whatever
happens these 302 Location: /booking/1
POST www ezy com/booking
1. happens, these state transitions are temporary.
happens, these state transitions are temporary.
If something fails, stop before moving If something fails,
stop before moving POST www.ezy.com/booking302 Location:/booking/X
are temporary.are temporary. stop before moving to phase 2
stop before moving to phase 2
PUT www.swiss.ch/booking/1
2 Onl idempotent Onl idempotent 2002. Only idempotent methods
are allowed in the
Only idempotent methods
are allowed in the
PUT www.ezy.com/booking/X200
are allowed in the confirmation
phase.
are allowed in the confirmation
phase.If something fails,
retry as many times If something fails,
retry as many times
©2011 - Cesare Pautasso 153
200 retry as many times as necessary
retry as many times as necessary
A matter of timing
Timeoutsio
nstr
ansi
tiSt
ate
t
1. Try
2. ConfirmTry Confirm
TimeTime
Agreement is reached if the confirmation phase ends before the f
©2011 - Cesare Pautasso 154
resources undo the state transitions because of the timeouts
A matter of timing
Timeoutsio
nstr
ansi
tiSt
ate
t
1. Try
2. ConfirmTry Confirm
TimeTime
If the confirmation runs longer than the earliest timeout we
©2011 - Cesare Pautasso 155
cannot guarantee agreement
Timeouts and heuristics Bad News: As with every distributed agreement
protocol, it is impossible to avoid heuristics Good News: thanks to the REST uniform interface we can always
d GET th URI f th r r d r r t do a GET on the URI of the reserved resource to see how much time we have left before it cancels Avoid starting phase 2 if there is not enough time Avoid starting phase 2 if there is not enough time
left to confirm with every service More complex preparation: if the resource allows it, More complex preparation: if the resource allows it,
extend the reservation time (also idempotent) before starting phase 2.
In any case, use a lightweight transaction coordinator to log everything for recovery and human diagnosis of heuristics
©2011 - Cesare Pautasso 156
heuristics
Architecture (Client-side Transaction)Try
1Client
ApplicationT
Confirm1
21
Try
Confirm13
Transaction
ConfirmConfirm 24
4
5
TransactionLibrary Try
4
4
ClientTCC
Confirm 2
©2011 - Cesare Pautasso 157
TCCResources
Architecture (Service Composition)T
W kfl
Try
Confirm0 1Client Workflow
EngineTry
Confirm0
62
1Try
Confirm13
5
Transaction
Confirm 24
4
5
a sact oCoordinator Try
4
CompositeRESTful TCC
Confirm 2
©2011 - Cesare Pautasso 158
ServiceTCC
Resources
Atomic Transactions for REST
The protocol guarantees atomicity in the event of failures among multiple interactions
i h RESTf l W b i h l i h with RESTful Web services that comply with the TCC pattern.(W t i t t d i i l ti ) (We are not interested in isolation)
No HTTP extension is required Fits very nicely with the REST uniform
interface and the idempotency of the PUT/DELETE methodsPUT/DELETE methods
Hypermedia can be easily built in to guide the discovery of the the discovery of the cancellation/confirmation URIs (e.g., with HTTP Link Headers)
©2011 - Cesare Pautasso 159
(e.g., with HTTP Link Headers)
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 REST is more at home with HTTP and HTML, while SOA is
more at home with SOAP and WSDL. Some REST advocates see the Web Services stack both as 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 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 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
©2011 - Cesare Pautasso 160
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, 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, Sept. 2008Business 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 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 S f S S S 2011
© 2011 - Cesare Pautasso 161
RESTful Services, In: REST: From Research to Practice, Springer, 2011 ISBN 978-1-4419-8302-2
SOA with REST
Raj Balasubramanian, Benjamin Carlyle Benjamin Carlyle, Thomas Erl, Cesare Pautasso, SOA ith REST SOA with REST, Prentice Hall, to appear in 2011pp
©2011 - Cesare Pautasso 162
http://ecows2011.inf.usi.ch/ http://ws-rest.org/book/http://ecows2011.inf.usi.ch/ p // g/ /
Service Oriented Architectures for the REST of Us
Cesare PautassoFaculty of Informatics
University of Lugano SwitzerlandUniversity of Lugano, Switzerland
[email protected] // t i fhttp://www.pautasso.info
@pautasso