REST vs. SOAP: Making the Right Architectural …

1 Symposium 2008, Amsterdam 2008 Cesare Pautasso1 REST vs. SOAP: Making the Right Architectural DecisionCesare PautassoFaculty of InformaticsUniversity of Lugano (USI), Symposium 2008, Amsterdam 2008 Cesare Pautasso2 Agenda1. Motivation: A short history of Web Services2. Comparing REST vs. SOAP/WS-*3. Architectural decision Modeling4. Conceptual Comparison5. Technology Comparison6. How to measure the complexity of WS-* or the simplicity of REST?7. Conclusion: Making the Right Architectural Symposium 2008, Amsterdam 2008 Cesare Pautasso3 Web Sites (1992)HTTPHTMLWeb BrowserWeb Server(HTTP)SOAPS erverClientXMLWSDLWS-*Web Services (2000) Symposium 2008, Amsterdam 2008 Cesare Pautasso4 RESTfulWeb Services (2006)ClientHTTPPO-XMLRSSJSONWeb ServerWADLWS-*Web Services (2000)(HTTP) Symposium 2008, Amsterdam 2008 Cesare Symposium 2008, Amsterdam 2008 Cesare Symposium 2008, Amsterdam 2008 Cesare Pautasso7Is REST being used?

2 Slide from Paul Downey, BT Symposium 2008, Amsterdam 2008 Cesare Pautasso8 Can we really compare WS-* vs. REST?WS-* Symposium 2008, Amsterdam 2008 Cesare Pautasso9 Can we really compare WS-* vs. REST?WS-*SOA MiddlewareInteroperabilityStandardsRESTA rchitecturalstyle for the Symposium 2008, Amsterdam 2008 Cesare Pautasso10 How to compare?WS-*SOA MiddlewareInteroperabilityStandardsRESTA rchitecturalstyle for the WebArchitecturalDecision Symposium 2008, Amsterdam 2008 Cesare Pautasso11 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 forintegration projects Architectural decisions affect one anotherArchitectural decision :Communication ProtocolArchitecture Alternatives:1. TCP2. SMTP3. HTTP4. MQ5. BEEP6. CORBA IIOP7.. Symposium 2008, Amsterdam 2008 Cesare Pautasso12 Application Integration StylesFile TransferShared DatabaseMessage BusRemoteProcedure CallWS-*RESTI ntegration Technology Symposium 2008, Amsterdam 2008 Cesare Pautasso13 Related Decisions (WS-*)File TransferShared DatabaseMessage BusRemoteProcedure CallWS-* Symposium 2008, Amsterdam 2008 Cesare Pautasso14 Related Decisions (RPC)File TransferShared DatabaseMessage BusRemoteProcedure CallWS-* Symposium 2008, Amsterdam 2008 Cesare Pautasso15 decision Space Symposium 2008, Amsterdam 2008 Cesare Pautasso16 decision Space Summary21 Decisions and 64 alternativesClassified by level of abstraction: 3 Architectural Principles 9 ConceptualDecisions 9 Technology-level DecisionsDecisions help us to measure the complexityimplied by the choice of REST or WS-* Symposium 2008, Amsterdam 2008 Cesare Pautasso17 Architectural Principles1.

3 Protocol Layering HTTP = Application-level Protocol (REST) HTTP = Transport-level Protocol(WS-*)2. Dealing with Heterogeneity3. Loose Symposium 2008, Amsterdam 2008 Cesare Pautasso18 RESTful Web Service ExampleHTTP Client(Web Browser)Web ServerDatabaseGET /book?ISBN=222 SELECT * FROM books WHERE isbn=222 POST /orderINSERT INTO orders301 Location: /order/612 PUT /order/612 UPDATE ordersWHERE id= Symposium 2008, Amsterdam 2008 Cesare Pautasso19 Big Web Service Example (from REST perspective)HTTP Client(Stub Object)Web ServerPOST /soap/endpointPOST /soap/endpointPOST /soap/endpointreturn getBook(222)return new Order() (x)Web Symposium 2008, Amsterdam 2008 Cesare Pautasso20 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 ApplicationResourceURIHTTPPOSTA pplicationEndpointURIPOXHTTPGETHTTPPUTHT TPDELHTTPPOSTSOAP (WS-*)

4 Symposium 2008, Amsterdam 2008 Cesare Pautasso21 Dealing with HeterogeneityCICSIMSP icture from Eric Newcomer, IONA Enterprise ComputingHTTP Web Symposium 2008, Amsterdam 2008 Cesare Pautasso22 Conceptual ComparisonNote: this table will scroll up during the Symposium 2008, Amsterdam 2008 Cesare Pautasso23 Technology ComparisonNote: this table will scroll up during the Symposium 2008, Amsterdam 2008 Cesare Pautasso24 Measuring Complexity Architectural Decisions give a quantitative measureof the complexity of an Architectural design space: Total number of decisions For each decision , number of alternative options For each alternative option, estimate the effort3527 Alternatives1417 DecisionsWS-*RESTD ecisions with1 or more alternative Symposium 2008, Amsterdam 2008 Cesare Pautasso25 Measuring Complexity3527 Alternatives1417 DecisionsWS-*RESTD ecisions with1 or more alternative options3216 Alternatives125 DecisionsWS-*RESTD ecisions withmore than 1 alternative Symposium 2008, Amsterdam 2008 Cesare Pautasso26 Measuring Complexity3216 Alternatives125 DecisionsWS-*RESTD ecisions withmore than 1 alternative options URI Design Resource Interaction Semantics Payload Format Service Description Service Symposium 2008.

5 Amsterdam 2008 Cesare Pautasso27 Measuring Complexity3216 Alternatives125 DecisionsWS-*RESTD ecisions withmore than 1 alternative options212 DecisionsWS-*RESTD ecisions withonly 1 alternative Symposium 2008, Amsterdam 2008 Cesare Pautasso28 Measuring Complexity212 DecisionsWS-*RESTD ecisions withonly 1 alternative option Payload Format Data Representation Symposium 2008, Amsterdam 2008 Cesare Pautasso29 Measuring Effort212 DecisionsWS-*RESTD ecisions withonly 1 alternative option05Do-it-yourself AlternativesWS-*RESTD ecisions with onlydo-it-yourself Symposium 2008, Amsterdam 2008 Cesare Pautasso30 Measuring Effort05Do-it-yourself AlternativesWS-*RESTD ecisions with onlydo-it-yourself alternatives Resource Identification Resource Relationship Reliability Transactions Service Symposium 2008, Amsterdam 2008 Cesare Pautasso31 Freedom of ChoiceFreedom from Symposium 2008, Amsterdam 2008 Cesare Pautasso32 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 aredo-it-yourself) WS-* complexity= freedom of choice 12 decisions require to choose among 32 alternatives 2 decisions are already taken (SOAP, WSDL+XSD) Symposium 2008, Amsterdam 2008 Cesare Pautasso33 Conclusion You should focus on whatever solution gets the job done and try to avoid being religiousabout any specific architectures or technologies.

6 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 Symposium 2008, Amsterdam 2008 Cesare Pautasso34 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 MegaprogrammingIn: Proceedings of the 5th VLDB Workshop on Technologies for E-Services (TES-04), Toronto, Canada, August 29-30, Symposium 2008, Amsterdam 2008 Cesare Pautasso35 REST vs.

7 SOAP: Making the Right Architectural DecisionCesare PautassoFaculty of InformaticsUniversity of Lugano (USI), Symposium 2008, Amsterdam 2008 Cesare Pautasso36 Backup Materialon RESTC esare PautassoFaculty of InformaticsUniversity of Lugano (USI), Symposium 2008, Amsterdam 2008 Cesare Pautasso37 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 them1. Resource Identificationthrough URI2. Uniform Interfacefor 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. Hyperlinksto define relationships between resources and valid state transitions of the service Symposium 2008, Amsterdam 2008 Cesare Pautasso38 URI: Uniform Resource Identifier Internet Standard for resource naming and identification (originally from 1994, revised until 2005) Examples: #1 REST advocates the use of nice URIs In most HTTP stacks URIs cannot have arbitrary length (4Kb)URI Symposium 2008, Amsterdam 2008 Cesare Pautasso39 What is a nice URI?

8 ,+switzerland&layer=&ie=UTF8&z=12&om=1&i wloc= Nouns to VerbsKeep them Symposium 2008, Amsterdam 2008 Cesare Pautasso40 Uniform Interface Principle (CRUD Example)DELETEUPDATEREADCREATECRUDC lear a resource, after the URI is no longer validModify the state of a resourceRetrieve the current state of the resourceInitialize the state of a new resource at the given Symposium 2008, Amsterdam 2008 Cesare Pautasso41 POST vs. GET GET is a read-onlyoperation. It can be repeated without affecting the state of the resource (idem-potent) POST is a read-writeoperation and may change the state of the resource and provoke side effects on the browsers warn you when refreshing a page generated with Symposium 2008, Amsterdam 2008 Cesare Pautasso42 RESTful Web Services Design1. Identify resources to be exposed as services ( , yearly risk report, book catalog, purchase order, open bugs)2. Define nice URLs to address them3.

9 Understand what it means to do a GET, POST, PUT, DELETE on a given resource URI4. Design and document resource representations (payload formats)5. Model relationships ( , containment, reference, state transitions) between resources with hyperlinks that can be followed to get more details6. Implement and deploy on Web server7. Test with a Web browserXXX/soap??/order/book?/clientXXX/ Symposium 2008, Amsterdam 2008 Cesare Pautasso43 XML PO-XML SOAP (WS-*) RSS, ATOM Standard textual syntax for semi-structured data Many tools available: XML Schema, DOM, SAX, XPath, XSLT, XQuery Everyone can parse it (not necessarily understand it) Slow and Verbose JavaScript Object Notation (JSON) Wire format introduced for AJAX Web applications (Browser-Web 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 Resource Representation Formats: XML vs JSON