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

Agenda 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? Conclusion: Making the right Architectural Decision

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?

Conclusion: Making the right Architectural Decision

Web Sites (1992) HTTP HTML Web Browser Web Server

Web Sites (1992) HTTP HTML Web Browser Web Server (HTTP) SOAP Server Client XML WSDL WS-* Web Services (2000)

RESTful Web Services (2006) Client HTTP PO-XML RSS JSON Web Server WADL WS-* Web Services (2000) (HTTP) SOAP Server Client XML WSDL

XML URI HTTP MIME JSON RESTful SSL RSS

Is REST being used? Slide from Paul Downey, BT

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

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

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

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

Architectural Decisions Architectural decisions capture the main design issues and the rationale behind a chosen technical solution The choice between REST vs. WS-* is an important architectural decision for integration projects Architectural decisions affect one another Architectural Decision: Communication Protocol Architecture Alternatives: TCP SMTP HTTP MQ BEEP CORBA IIOP … Rationale

Architectural decisions capture the main design issues and the rationale behind a chosen technical solution

The choice between REST vs. WS-* is an important architectural decision for integration projects

Architectural decisions affect one another

Architectural Decision:

Communication Protocol

Architecture Alternatives:

TCP

SMTP

HTTP

MQ

BEEP

CORBA IIOP

…

Rationale

Application Integration Styles File Transfer Shared Database Message Bus Remote Procedure Call

Application Integration Styles File Transfer Shared Database Message Bus Remote Procedure Call WS-* REST Integration Technology Platform

Related Decisions (WS-*) File Transfer Shared Database Message Bus Remote Procedure Call WS-* REST

Related Decisions (RPC) File Transfer Shared Database Message Bus Remote Procedure Call WS-* REST

Decision Space Overview

Decision Space Summary 21 Decisions and 64 alternatives Classified by level of abstraction: 3 Architectural Principles 9 Conceptual Decisions 9 Technology -level Decisions

21 Decisions and 64 alternatives

Classified by level of abstraction:

3 Architectural Principles

9 Conceptual Decisions

9 Technology -level Decisions

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

21 Decisions and 64 alternatives

Classified by level of abstraction:

3 Architectural Principles

9 Conceptual Decisions

9 Technology -level Decisions

Decisions help us to measure the complexity implied by the choice of REST or WS-*

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

Protocol Layering

HTTP = Application-level Protocol (REST)

HTTP = Transport-level Protocol (WS-*)

Dealing with Heterogeneity

Loose Coupling

RESTful Web Service Example HTTP Client (Web Browser) Web Server Database GET /book?ISBN=222 SELECT * FROM books WHERE isbn=222 POST /order INSERT INTO orders 301 Location: /order/612 PUT /order/612 UPDATE orders WHERE id=612

Big Web Service Example (from REST perspective) HTTP Client (Stub Object) Web Server POST /soap/endpoint POST /soap/endpoint return new Order() order.setCustomer(x) Web Service Implementation POST /soap/endpoint return getBook(222)

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” Application Resource URI HTTP POST Application Endpoint URI POX HTTP GET HTTP PUT HTTP DEL HTTP POST SOAP (WS-*) MQ… SMTP RSS JSON …

“ 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”

Dealing with Heterogeneity Enterprise Computing Web Applications CICS IMS Picture from Eric Newcomer, IONA HTTP

Enterprise Computing

Web Applications

Dealing with Heterogeneity Enterprise Computing Web Applications CICS IMS Picture from Eric Newcomer, IONA HTTP

Enterprise Computing

Web Applications

Conceptual Comparison

Conceptual Comparison

Conceptual Comparison

Technology Comparison

Technology Comparison

Technology Comparison

Technology Comparison

Technology Comparison

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

Architectural Decisions give a quantitative measure of the complexity of an architectural design space:

Total number of decisions

For each decision, number of alternative options

For each alternative option, estimate the effort

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

Measuring Complexity Decisions with more than 1 alternative options URI Design Resource Interaction Semantics Payload Format Service Description Service Composition 32 16 Alternatives 12 5 Decisions WS-* REST

URI Design

Resource Interaction Semantics

Payload Format

Service Description

Service Composition

Measuring Complexity Decisions with more than 1 alternative options Decisions with only 1 alternative option 32 16 Alternatives 12 5 Decisions WS-* REST 2 12 Decisions WS-* REST

Measuring Complexity Decisions with only 1 alternative option Payload Format Data Representation Modeling 2 12 Decisions WS-* REST

Payload Format

Data Representation Modeling

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

Measuring Effort Decisions with only do-it-yourself alternatives Resource Identification Resource Relationship Reliability Transactions Service Discovery 0 5 Do-it-yourself Alternatives WS-* REST

Resource Identification

Resource Relationship

Reliability

Transactions

Service Discovery

Freedom of Choice Freedom from Choice

Comparison Summary Architectural Decisions measure complexity implied by alternative technologies REST simplicity = freedom from choice 5 decisions require to choose among 16 alternatives 12 decisions are already taken ( but 5 are do-it-yourself ) WS-* complexity = freedom of choice 12 decisions require to choose among 32 alternatives 2 decisions are already taken (SOAP, WSDL+XSD)

Architectural Decisions measure complexity implied by alternative technologies

REST simplicity = freedom from choice

5 decisions require to choose among 16 alternatives

12 decisions are already taken ( but 5 are do-it-yourself )

WS-* complexity = freedom of choice

12 decisions require to choose among 32 alternatives

2 decisions are already taken (SOAP, WSDL+XSD)

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

You should focus on whatever solution gets the job done and try to avoid being religious about any specific architectures or technologies.

WS-* has strengths and weaknesses and will be highly suitable to some applications and positively terrible for others. Likewise with REST.

The decision of which to use depends entirely on the application requirements and constraints.

We hope this comparison will help you make the right choice.

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

Cesare Pautasso, Olaf Zimmermann, Frank Leymann,

RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision , Proc. of the 17th International World Wide Web Conference ( WWW2008 ), Bejing, China, April 2008.

Cesare Pautasso, BPEL for REST , Proc. of the 6th International Conference on Business Process Management ( BPM 2008 ), Milan, Italy, September 2008.

Cesare Pautasso, Gustavo Alonso: From Web Service Composition to Megaprogramming Proc. of the 5th VLDB Workshop on Technologies for E-Services (TES-04), Toronto, Canada, August 29-30, 2004.