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.


Outline Introduction What is REST? RESTful Service Design RESTful Web Services within the Enterprise


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


SOA RESTSOA REST


RESTfulWeb ServicesService

OrientedWeb Services

OrientedArchitecturesc tectu es

WS-*Web Services


WS-* Standards Stack


WS-* Standards Stack

Int ManagementBPMtero M Re

Se

Tra Soper

Meta

eliabi

ecur

nsacti

Statrabi

adat

lity

rity

ions

e

lity

ta

Messaging


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?


with REST?

RESTful Services Standards

AtomPub

RSS Atom

AtomPub

XML JSON

RSS Atom

URI HTTP

JSON

MIME SSL/TLS


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


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


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


Web Sites (1992)

HTMLWeb Web HTTPBrowser Server

WS-* Web Services (2000)

SOAP WSDLServerClient XML


(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


(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


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)


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


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


Software Connectors

Fil T f

Shared Data

File Transfer

Shared Data

Procedure Call

Message Bus

Procedure CallRemote Procedure Call


Message BusEvents

What is your SOA connector today?

RPC BUS

REST/HTTP


REST as a new connector

RPC BUSPublish/Subscribe

Call

REST/HTTP

Get/Put/Post/Delete


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%


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


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


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


#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


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


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.


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


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.


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


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)


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


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?


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


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


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


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?


• 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)


Basic Setup

HTTP


Adding Caching

Caching Origin Server

HTTP

User Agent Caching

HTTP

CachingUser Agent

Origin Server User Agent CachingOrigin Server

HTTP

CachingUser Agent

CachingOrigin 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


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


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


Design SpaceM Representations (Variable)


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}


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 )


(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>


Simple Doodle API Example Existing votes can be updated (access control headers not shown)


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>


Simple Doodle API Example Polls can be deleted once a decision has been made


G / ll/090331

/p / / /

DELETE /poll/090331x

200 OK

GET /poll/090331x

404 Not Found200 OK 404 Not Found


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


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


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


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


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


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


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


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


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


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?


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:


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


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


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


( ) // 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


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


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


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


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.


Warning: do not create redirection loops!

Antipatterns - REST vs. HTTP

REST HTTPREST

“RPC”RESTful HTTP


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 )


(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>


</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


Heterogeneity

EnterpriseWeb EnterpriseArchitectures

WebApplications ArchitecturesApplications

REST WS-*REST WS


Heterogeneity

Web EnterpriseWebApplications

EnterpriseArchitecturesApplications Architectures

RESTREST

Claim: REST can also be successfully used t d i i t t d t i li ti


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


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


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


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?


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)


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


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


( ) 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?


Origin ServerHTTP

?

Origin Server

User Agent


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


Databases

BPM with REST

Process Model

RPublishingP

Act 1

Act 2

Act 7Act 5

Act 4 R Processesas Resources

Act 3 Act 6


RESTfulServiceR ServiceCompositionRR


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)


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>


...

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


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


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


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


Composite Resources The composite resource only aggregates the

state of its component resources

C

R SState

RState

S


Composite Resources The composite resource augments (or caches)

the state of its component resources

StateC

CC

R SState

RState

S


Composite Representations

PUT

DELETE

PUT

PUT

DELETE

GETR

C it GET

GETPOST

CS

Composite Representation

GETPOST

POSTC

i kLinkR

LinkLinkS


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


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


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


1. Composite Resource

PUT

DELETE

DELETEGETC

PUT

DELETEGET

POST PUT

DELETE

GETR

GETS

POST POST


1. Composite Resource

DELETE

GETC

GET

POST PUT

DELETE

GETR

GETS

POST


2. Composite Representation

GDELETEDM GETG

GETC

DELETE

LinkG

Li kGET

POST PUT

DELETELinkC

Li k

GETR

GETS

LinkD

POST


RESTful Composition Example


Example: Doodle Map Mashup

Setup a Doodle with Yahoo! Local search fand visualize the results of the poll on

Google Maps


Doodle Map Mashup Architecture

Web Browser Workflow RESTfulEngine Web Services

APIsGETfu

l API

GET

POSTRES

TfPOST

GET

ResourcesComposite Composite


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


Simply aggregating data (feeds)

Read-only vs. Read/write

GETC

GET

GETR

GETS


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


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


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


Complementary

Read-OnlyRead/WriteRead/Write

Mashup RESTMashup APIUI

RESTCompositionp

SituationalReusable

ServiceServiceSandboxed


BPM with REST

Process Model

RPublishingP

Act 1

Act 2

Act 7Act 5

Act 4 R Processesas Resources

Act 3 Act 6


RESTfulServiceR ServiceCompositionRR


BPM RESTBPM REST Resources/URIs

U if Processes

Uniform Interface

Tasks Control Flow te ace

Representations Control FlowData Flow

Hypermedia…


Everything is a resource

/process/X /process/X/1

ProcessProcessInstanceInstance

Task TaskInstanceInstance

/task/Y/task/Y/1


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


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


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


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 )


(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


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…


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

…


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}


Simple RESTBucks ExampleHypermedia Centric Service Design done with a business process model R

es

Privsou

vaterces

e Tass sks


Instantiating a process

GET /rest/restbucks/order/1.0/


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)


(the new instance)

Interacting with a task

GET /task/restbucks/order/1.0/0/payment


Interacting with a task

POST /rest/restbucks/order/1.0/0/payment


Interacting with a resource

GET /receipt/2fc7f6e2-8b43-4672-a7c4…


Interacting with a resource

DELETE /rest/restbucks/order/1.0/0


Deleting a process resource

DELETE /rest/restbucks/order/1.0/0


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?


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?


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?


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!)


(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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


heuristics

Architecture (Client-side Transaction)Try

1Client

ApplicationT

Confirm1

21

Try

Confirm13

Transaction

ConfirmConfirm 24

4

5

TransactionLibrary Try

4

4

ClientTCC

Confirm 2


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


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)


(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


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


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

service oriented architectures for the rest of us · 2011-04-25 · foundation for so-called...

Documents