WIXLIB

REST vs. SOAP:Making the RightArchitectural DecisionCesare PautassoFaculty of InformaticsUniversity of Lugano (USI), Switzerlandhttp://www.pautasso.info7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso1

Agenda1.2.3.4.5.6.Motivation: A short history of Web ServicesComparing REST vs. SOAP/WS-*Architectural Decision ModelingConceptual ComparisonTechnology ComparisonHow to measure the “complexity” of WS-*or the “simplicity” of REST?7. Conclusion: Making the right ArchitecturalDecision7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso2

Web Sites (1992)WebBrowserHTMLHTTPWebServerWS-* Web Services (2000)SOAPClient7.10.2008XML(HTTP)SOA Symposium 2008, Amsterdam 2008 Cesare PautassoWSDLServer3

RESTful Web Services (2006)RSSPO-XMLJSONClientHTTPWADLWebServerWS-* Web Services (2000)SOAPClient7.10.2008XML(HTTP)SOA Symposium 2008, Amsterdam 2008 Cesare PautassoWSDLServer4

7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso5

RESTfulRSSJSONXMLMIMEURIHTTPSSL7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso6

Is REST being used?Slide from Paul Downey, BT7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso7

Can we really compareWS-* vs. REST?RESTWS-*7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso8

Can we really compareWS-* vs. REST?WS-*RESTSOA yle forthe Web7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso9

How to style forthe WebWS-*SOA A Symposium 2008, Amsterdam 2008 Cesare Pautasso10

Architectural Decisions Architectural decisionscapture the main designissues and the rationalebehind a chosen technicalsolution The choice between RESTvs. WS-* is an importantarchitectural decision forintegration projects Architectural decisionsaffect one anotherArchitectural Decision:Communication ProtocolArchitecture Alternatives:1. TCP2. SMTP3. HTTP4. MQ5. BEEP6. CORBA IIOP7. Rationale7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso11

Application Integration StylesSharedDatabaseRemoteProcedureCallRESTMessage BusFileTransferWS-*Integration Technology Platform7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso12

Related Decisions 08Message BusFileTransferWS-*SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso13

Related Decisions 8Message BusFileTransferWS-*SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso14

Decision Space Overview7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso15

Decision Space Summary21 Decisions and 64 alternativesClassified by level of abstraction: 3 Architectural Principles 9 Conceptual Decisions 9 Technology-level DecisionsDecisions help us to measure thecomplexity implied by the choice ofREST or WS-*7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso16

Architectural Principles1. Protocol Layering HTTP Application-level Protocol (REST) HTTP Transport-level Protocol(WS-*)2. Dealing with Heterogeneity3. Loose Coupling7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso17

RESTful Web Service ExampleHTTP ClientWeb ServerDatabase(Web Browser)GET /book?ISBN 222POST /order301 Location: /order/612PUT /order/6127.10.2008SELECT *FROM booksWHERE isbn 222INSERTINTO ordersUPDATE ordersWHERE id 612SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso18

Big Web Service Example(from REST perspective)HTTP ClientWeb Server(Stub Object)POST /soap/endpointPOST /soap/endpointPOST /soap/endpoint7.10.2008Web ServiceImplementationreturn getBook(222)return new Order()order.setCustomer(x)SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso19

Protocol Layering “The Web is the universe of globallyaccessible information”(Tim Berners Lee)– Applications should publish theirdata on the Web (through URI) “The Web is the universal (tunneling)transport for messages”– Applications get a chance tointeract but they remain“outside of the Web”POXRSSJSON SOAP 08SMTPResource URIEndpoint URIApplicationApplicationSOA Symposium 2008, Amsterdam 2008 Cesare PautassoMQ 20

Dealing with Heterogeneity Web Applications Enterprise ComputingCICSIMS7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare PautassoPicture from Eric Newcomer, IONAHTTP21

Conceptual ComparisonNote: this tablewill scroll upduring the talk7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso22

Technology ComparisonNote: this tablewill scroll upduring the talk7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso23

Measuring Complexity Architectural Decisions give aquantitative measure of the complexityof an architectural design space:– Total number of decisions– For each decision, number of alternative options– For each alternative option, estimate the ns with 1 or more alternative options7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso24

Measuring sions with more than 1 alternative ons with 1 or more alternative options7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso25

Measuring sions with more than 1 alternative options URI Design Resource Interaction Semantics Payload Format Service Description Service Composition7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso26

Measuring sions with more than 1 alternative optionsDecisionsREST12WS-*2Decisions with only 1 alternative option7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso27

Measuring Complexity Payload Format Data Representation ModelingDecisionsREST12WS-*2Decisions with only 1 alternative option7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso28

Measuring s with only do-it-yourself alternativesDecisionsREST12WS-*2Decisions with only 1 alternative option7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso29

Measuring s with only do-it-yourself alternatives Resource Identification Resource Relationship Reliability Transactions Service Discovery7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso30

Freedom of ChoiceFreedom from Choice7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso31

Comparison Summary Architectural Decisions measure complexity impliedby 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)7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso32

Conclusion You should focus on whatever solution gets the jobdone and try to avoid being religious about anyspecific architectures or technologies. WS-* has strengths and weaknesses and will behighly suitable to some applications and positivelyterrible for others. Likewise with REST. The decision of which to use depends entirely on theapplication requirements and constraints. We hope this comparison will help you make the rightchoice.7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso33

References Cesare Pautasso, Olaf Zimmermann, Frank Leymann,RESTful Web Services vs. Big Web Services: Making the RightArchitectural Decision, Proc. of the 17th International World WideWeb Conference (WWW2008), Bejing, China, April 2008. Cesare Pautasso, BPEL for REST, Proc. of the 6th InternationalConference on Business Process Management (BPM 2008), Milan,Italy, September 2008. Cesare Pautasso, Gustavo Alonso: From Web Service Compositionto Megaprogramming In: Proceedings of the 5th VLDB Workshop onTechnologies for E-Services (TES-04), Toronto, Canada, August 2930, 2004.7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso34

REST vs. SOAP:Making the RightArchitectural DecisionCesare PautassoFaculty of InformaticsUniversity of Lugano (USI), Switzerlandhttp://www.pautasso.info7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso35

Backup Materialon RESTCesare PautassoFaculty of InformaticsUniversity of Lugano (USI), Switzerlandhttp://www.pautasso.info7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso36

REST in one Slide REpresentational State Transfer defines the architecturalstyle of the World Wide Web Its four principles can explain the success and thescalability of the HTTP protocol implementing them1. Resource Identification through URI2. Uniform Interface for all resources: GET (Query the state, idempotent, can be cached) POST (Update a resource or create child resource) PUT (Transfer the state on existing/new resource) DELETE (Delete a resource)3. “Self-Descriptive” Message representations4. Hyperlinks to define relationships between resourcesand valid state transitions of the service interaction7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso37

URI: Uniform Resource Identifier Internet Standard for resource naming and identification(originally from 1994, revised until 2005) Examples:http://tools.ietf.org/html/rfc3986URI SchemeAuthorityPathhttps://www.google.ch/search?q rest&start 10#1QueryFragment REST advocates the use of “nice” URIs In most HTTP stacks URIs cannot have arbitrary length (4Kb)7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso38

What is a “nice” URI?Prefer Nouns to Verbshttp://map.search.ch/luganoKeep them le.com/maps?f q&hl en&q lugano, switzerland&layer &ie UTF8&z 12&om 1&iwloc addr7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso39

Uniform Interface Principle(CRUD TEDELETE7.10.2008Initialize the state of anew resourceat the given URIRetrieve the currentstate of the resourceModify the stateof a resourceClear a resource,after the URI is nolonger validSOA Symposium 2008, Amsterdam 2008 Cesare Pautasso40

POST vs. GET GET is a read-only operation.It can be repeated withoutaffecting the state of theresource (idem-potent) POST is a read-writeoperation and may changethe state of the resourceand provoke side effects onthe server.Web browsers warnyou when refreshinga page generatedwith POST7.10.2008SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso41

RESTful Web Services DesignPUTPOSTDELETE7.10.2008GET1. Identify resources to be exposed asservices (e.g., yearly risk report, bookcatalog, purchase order, open bugs)2. Define “nice” URLs to address them3. Understand what it means to do a GET,POST, PUT, DELETE on a given resourceURI4. Design and document resourcerepresentations (payload formats)5. Model relationships (e.g., containment,reference, state transitions) betweenresources with hyperlinks that can befollowed to get more details6. Implement and deploy on Web server7. Test with a Web A Symposium 2008, Amsterdam 2008 Cesare PautassoXX?X42

Resource RepresentationFormats: XML vs JSON XML– PO-XML– SOAP (WS-*)– RSS, ATOM Standard textual syntax forsemi-structured data Many tools available:XML Schema, DOM, SAX, XPath,XSLT, XQuery Everyone can parse it(not necessarily understand it) Slow and Verbose7.10.2008 JavaScript Object Notation (JSON) Wire format introduced for AJAXWeb applications (BrowserWeb Server communication) Textual syntax for serialization ofnon-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, Amsterdam 2008 Cesare Pautasso43

Remote Message Bus Procedure Call REST WS-* . Enterprise Computing HTTP Web Applications. 7.10.2008 SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso 22 . and valid state transitions of the service interaction. 7.10.2008 SOA Symposium 2008, Amsterdam 2008 Cesare Pautasso 38