You are on page 1of 43

REST vs.

SOAP: Making the Right Architectural Decision
Cesare Pautasso
Faculty of Informatics University of Lugano (USI), Switzerland http://www.pautasso.info
7.10.2008 1

SOA Symposium 2008, Amsterdam ©2008 Cesare Pautasso

Agenda
1. 2. 3. 4. 5. 6. Motivation: A short history of Web Services Comparing REST vs. SOAP/WS-* Architectural Decision Modeling Conceptual Comparison Technology Comparison How to measure the “complexity” of WS-* or the “simplicity” of REST? 7. Conclusion: Making the right Architectural Decision
7.10.2008 SOA Symposium 2008, Amsterdam ©2008 Cesare Pautasso 2

Web Sites (1992)

Web Browser

HTML HTTP

Web Server

WS-* Web Services (2000)
SOAP Client
7.10.2008

WSDL Server
3

XML (HTTP) Amsterdam SOA Symposium 2008,
©2008 Cesare Pautasso

RESTful Web Services (2006)
PO-XML JSON RSS WADL Web Server

Client

HTTP

WS-* Web Services (2000)
SOAP Client
7.10.2008

WSDL Server
4

XML (HTTP) Amsterdam SOA Symposium 2008,
©2008 Cesare Pautasso

7.10.2008 SOA Symposium 2008. Amsterdam ©2008 Cesare Pautasso 5 .

Amsterdam ©2008 Cesare Pautasso 6 .2008 SOA Symposium 2008.RESTful RSS XML JSON MIME URI HTTP SSL 7.10.

Is REST being used? Slide from Paul Downey.10.2008 SOA Symposium 2008. BT 7. Amsterdam ©2008 Cesare Pautasso 7 .

Amsterdam ©2008 Cesare Pautasso 8 .2008 SOA Symposium 2008.Can we really compare WS-* vs. REST? WS-* REST 7.10.

REST? WS-* SOA Middleware Interoperability Standards REST Architectural style for the Web 7.Can we really compare WS-* vs.10. Amsterdam ©2008 Cesare Pautasso 9 .2008 SOA Symposium 2008.

Amsterdam ©2008 Cesare Pautasso REST Architectural style for the Web 10 .10.2008 SOA Symposium 2008.How to compare? itectural Arch Modeling Decision WS-* SOA Middleware Interoperability Standards 7.

Amsterdam ©2008 Cesare Pautasso 11 . TCP 2. CORBA IIOP 7. SMTP 3. BEEP 6.Architectural Decisions • Architectural decisions capture the main design issues and the rationale behind a chosen technical solution • The choice between REST vs.2008 SOA Symposium 2008.10. … Rationale 7. HTTP 4. WS-* is an important architectural decision for integration projects • Architectural decisions affect one another Architectural Decision: Communication Protocol Architecture Alternatives: 1. MQ 5.

10.2008 SOA Symposium 2008. Amsterdam ©2008 Cesare Pautasso 12 .Application Integration Styles Shared Database Remote Procedure Call Message Bus File Transfer REST WS-* Integration Technology Platform 7.

Amsterdam ©2008 Cesare Pautasso 13 .2008 SOA Symposium 2008.Related Decisions (WS-*) Shared Database Remote Procedure Call Message Bus File Transfer REST WS-* 7.10.

10. Amsterdam ©2008 Cesare Pautasso 14 .2008 SOA Symposium 2008.Related Decisions (RPC) Shared Database Remote Procedure Call Message Bus File Transfer REST WS-* 7.

Amsterdam ©2008 Cesare Pautasso 15 .2008 SOA Symposium 2008.Decision Space Overview 7.10.

2008 SOA Symposium 2008.Decision Space Summary 21 Decisions and 64 alternatives Classified by level of abstraction: • 3 Architectural Principles • 9 Conceptual Decisions • 9 Technology-level Decisions Decisions help us to measure the complexity implied by the choice of REST or WS-* 7. Amsterdam ©2008 Cesare Pautasso 16 .10.

Dealing with Heterogeneity 3. Loose Coupling 7.Architectural Principles 1.2008 SOA Symposium 2008. Amsterdam ©2008 Cesare Pautasso 17 .10. Protocol Layering • HTTP = Application-level Protocol (REST) • HTTP = Transport-level Protocol (WS-*) 2.

10.2008 SELECT * FROM books WHERE isbn=222 INSERT INTO orders UPDATE orders WHERE id=612 18 SOA Symposium 2008.RESTful Web Service Example HTTP Client (Web Browser) Web Server Database GET /book?ISBN=222 POST /order 301 Location: /order/612 PUT /order/612 7. Amsterdam ©2008 Cesare Pautasso .

setCustomer(x) 7.2008 SOA Symposium 2008.10. Amsterdam ©2008 Cesare Pautasso 19 .Big Web Service Example (from REST perspective) HTTP Client (Stub Object) Web Server Web Service Implementation POST /soap/endpoint POST /soap/endpoint POST /soap/endpoint return getBook(222) return new Order() order.

10.2008 SOA Symposium 2008.Protocol Layering • “The Web is the universe of globally accessible information” (Tim Berners Lee) – Applications should publish their data on the Web (through URI) • “The Web is the universal (tunneling) transport for messages” – Applications get a chance to interact but they remain “outside of the Web” POX HTTP GET RSS HTTP POST JSON HTTP PUT … HTTP DEL SMTP SOAP (WS-*) HTTP POST Endpoint URI Application MQ… Resource URI Application 7. Amsterdam ©2008 Cesare Pautasso 20 .

IONA HTTP CICS IMS 7.Dealing with Heterogeneity • Web Applications • Enterprise Computing Picture from Eric Newcomer.2008 SOA Symposium 2008.10. Amsterdam ©2008 Cesare Pautasso 21 .

10. Amsterdam ©2008 Cesare Pautasso .Conceptual Comparison Note: this table will scroll up during the talk 7.2008 22 SOA Symposium 2008.

2008 SOA Symposium 2008.Technology Comparison Note: this table will scroll up during the talk 7. Amsterdam ©2008 Cesare Pautasso 23 .10.

10.Measuring Complexity • Architectural Decisions give a quantitative measure of the complexity of an architectural design space: – Total number of decisions – For each decision. estimate the effort Decisions Alternatives 7. number of alternative options – For each alternative option. Amsterdam ©2008 Cesare Pautasso WS-* 14 35 24 Decisions with 1 or more alternative options .2008 REST 17 27 SOA Symposium 2008.

Amsterdam ©2008 Cesare Pautasso WS-* 14 35 25 Decisions with 1 or more alternative options .Measuring Complexity Decisions Alternatives REST 5 16 WS-* 12 32 Decisions with more than 1 alternative options Decisions Alternatives 7.2008 REST 17 27 SOA Symposium 2008.10.

10. Amsterdam ©2008 Cesare Pautasso 26 .2008 SOA Symposium 2008.Measuring Complexity Decisions Alternatives REST 5 16 WS-* 12 32 Decisions with more than 1 alternative options • URI Design • Resource Interaction Semantics • Payload Format • Service Description • Service Composition 7.

Amsterdam ©2008 Cesare Pautasso 27 .10.Measuring Complexity Decisions Alternatives REST 5 16 WS-* 12 32 Decisions with more than 1 alternative options Decisions REST 12 WS-* 2 Decisions with only 1 alternative option 7.2008 SOA Symposium 2008.

10. Amsterdam ©2008 Cesare Pautasso 28 .2008 SOA Symposium 2008.Measuring Complexity • Payload Format • Data Representation Modeling Decisions REST 12 WS-* 2 Decisions with only 1 alternative option 7.

Amsterdam ©2008 Cesare Pautasso 29 .2008 SOA Symposium 2008.Measuring Effort Do-it-yourself Alternatives REST 5 WS-* 0 Decisions with only do-it-yourself alternatives Decisions REST 12 WS-* 2 Decisions with only 1 alternative option 7.10.

10. Amsterdam ©2008 Cesare Pautasso 30 .Measuring Effort Do-it-yourself Alternatives REST 5 WS-* 0 Decisions with only do-it-yourself alternatives • Resource Identification • Resource Relationship • Reliability • Transactions • Service Discovery 7.2008 SOA Symposium 2008.

10. Amsterdam ©2008 Cesare Pautasso 31 .Freedom of Choice Freedom from Choice 7.2008 SOA Symposium 2008.

WSDL+XSD) 7.10.2008 SOA Symposium 2008.Comparison Summary • Architectural Decisions measure complexity implied by alternative technologies • REST simplicity = freedom from choice – 5 decisions require to choose among 16 alternatives – 12 decisions are already taken (but 5 are do-it-yourself) • WS-* complexity = freedom of choice – 12 decisions require to choose among 32 alternatives – 2 decisions are already taken (SOAP. Amsterdam ©2008 Cesare Pautasso 32 .

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

• Cesare Pautasso. 7. August 2930.10. Canada. Milan. 2004. of the 6th International Conference on Business Process Management (BPM 2008). Proc. Bejing. Gustavo Alonso: From Web Service Composition to Megaprogramming In: Proceedings of the 5th VLDB Workshop on Technologies for E-Services (TES-04). September 2008. Toronto. Italy.2008 SOA Symposium 2008. Olaf Zimmermann. Proc. • Cesare Pautasso. April 2008. Frank Leymann. Big Web Services: Making the Right Architectural Decision.References • Cesare Pautasso. Amsterdam ©2008 Cesare Pautasso 34 . China. of the 17th International World Wide Web Conference (WWW2008). RESTful Web Services vs. BPEL for REST.

info 7.REST vs. Switzerland http://www. Amsterdam ©2008 Cesare Pautasso .2008 35 SOA Symposium 2008.pautasso. SOAP: Making the Right Architectural Decision Cesare Pautasso Faculty of Informatics University of Lugano (USI).10.

Backup Material on REST Cesare Pautasso Faculty of Informatics University of Lugano (USI). Switzerland http://www.info 7.pautasso.10.2008 36 SOA Symposium 2008. Amsterdam ©2008 Cesare Pautasso .

“Self-Descriptive” Message representations 4.10. Hyperlinks to define relationships between resources and valid state transitions of the service interaction 7. Uniform Interface for all resources: GET (Query the state.REST in one Slide • REpresentational State Transfer defines the architectural style of the World Wide Web • Its four principles can explain the success and the scalability of the HTTP protocol implementing them 1. can be cached) POST (Update a resource or create child resource) PUT (Transfer the state on existing/new resource) DELETE (Delete a resource) 3.2008 SOA Symposium 2008. idempotent. Resource Identification through URI 2. Amsterdam ©2008 Cesare Pautasso 37 .

revised until 2005) • Examples: http://tools.google.ietf.10. Amsterdam ©2008 Cesare Pautasso 38 .org/html/rfc3986 URI Scheme Authority Path https://www.ch/search?q=rest&start=10#1 Query Fragment • REST advocates the use of “nice” URIs • In most HTTP stacks URIs cannot have arbitrary length (4Kb) 7.URI: Uniform Resource Identifier • Internet Standard for resource naming and identification (originally from 1994.2008 SOA Symposium 2008.

google. +switzerland&layer=&ie=UTF8&z=12&om=1&iwloc=addr 7. Amsterdam ©2008 Cesare Pautasso 39 .What is a “nice” URI? Prefer Nouns to Verbs http://map.10.com/maps?f=q&hl=en&q=lugano.com/lugano http://maps.ch/lugano Keep them Short http://maps.2008 SOA Symposium 2008.search.google.

Uniform Interface Principle (CRUD Example) CRUD CREATE READ UPDATE DELETE 7. Amsterdam ©2008 Cesare Pautasso .2008 REST POST/PUT GET PUT DELETE Initialize the state of a new resource at the given URI Retrieve the current state of the resource Modify the state of a resource Clear a resource.10. after the URI is no longer valid 40 SOA Symposium 2008.

It can be repeated without affecting the state of the resource (idem-potent) • POST is a read-write operation and may change the state of the resource and provoke side effects on the server.2008 SOA Symposium 2008.10. Web browsers warn you when refreshing a page generated with POST 7. Amsterdam ©2008 Cesare Pautasso 41 . GET • GET is a read-only operation.POST vs.

Design and document resource representations (payload formats) 5.. Model relationships (e. Implement and deploy on Web server 7.g..RESTful Web Services Design 1. yearly risk report.10. Understand what it means to do a GET. open bugs) 2. state transitions) between resources with hyperlinks that can be followed to get more details 6. book catalog.g. purchase order. reference. Define “nice” URLs to address them 3. DELETE on a given resource URI 4. containment. Identify resources to be exposed as services (e. POST. Test with a Web browser 7. Amsterdam ©2008 Cesare Pautasso . PUT.2008 DELETE POST GET /loan /balance /client /book /order X /soap PUT X X X X ? ? ? X 42 SOA Symposium 2008.

Resource Representation Formats: XML vs JSON • XML – PO-XML – SOAP (WS-*) – RSS. Amsterdam ©2008 Cesare Pautasso 43 . XPath. DOM. SAX.2008 • JavaScript Object Notation (JSON) • Wire format introduced for AJAX Web applications (BrowserWeb Server communication) • Textual syntax for serialization of non-recurrent data structures • Supported in most languages (not only JavaScript) • Not extensible (does not need to be) • “JSON has become the X in Ajax” SOA Symposium 2008.10. XSLT. ATOM • Standard textual syntax for semi-structured data • Many tools available: XML Schema. XQuery • Everyone can parse it (not necessarily understand it) • Slow and Verbose 7.