Cesare Pautasso R E S T V1

1,808 views
1,691 views

Published on

Published in: Technology, Travel
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,808
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
33
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Cesare Pautasso R E S T V1

  1. 1. This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.com Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors
  2. 2. 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 SOA Symposium 2008, Amsterdam 1 ©2008 Cesare Pautasso
  3. 3. Agenda 1. Motivation: A short history of Web Services 2. Comparing REST vs. SOAP/WS-* 3. Architectural Decision Modeling 4. Conceptual Comparison 5. Technology Comparison 6. 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 2 ©2008 Cesare Pautasso
  4. 4. Web Sites (1992) Web HTML Web Browser HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server 7.10.2008 (HTTP) Amsterdam SOA Symposium 2008, 3 ©2008 Cesare Pautasso
  5. 5. RESTful Web Services (2006) PO-XML JSON RSS WADL Web Client HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server 7.10.2008 (HTTP) Amsterdam SOA Symposium 2008, 4 ©2008 Cesare Pautasso
  6. 6. 7.10.2008 SOA Symposium 2008, Amsterdam 5 ©2008 Cesare Pautasso
  7. 7. RESTful RSS XML JSON MIME URI HTTP SSL 7.10.2008 SOA Symposium 2008, Amsterdam 6 ©2008 Cesare Pautasso
  8. 8. Is REST being used? Slide from Paul Downey, BT 7.10.2008 SOA Symposium 2008, Amsterdam 7 ©2008 Cesare Pautasso
  9. 9. Can we really compare WS-* vs. REST? WS-* REST 7.10.2008 SOA Symposium 2008, Amsterdam 8 ©2008 Cesare Pautasso
  10. 10. Can we really compare WS-* vs. REST? WS-* REST SOA Middleware Architectural Interoperability style for Standards the Web 7.10.2008 SOA Symposium 2008, Amsterdam 9 ©2008 Cesare Pautasso
  11. 11. How to compare? Arch itectural Decision Modeling REST WS-* Architectural style for SOA Middleware the Web Interoperability Standards 7.10.2008 SOA Symposium 2008, Amsterdam 10 ©2008 Cesare Pautasso
  12. 12. Architectural Decisions • Architectural decisions Architectural Decision: capture the main design Communication Protocol issues and the rationale behind a chosen technical Architecture Alternatives: solution 1. TCP • The choice between REST 2. SMTP vs. WS-* is an important 3. HTTP architectural decision for 4. MQ integration projects 5. BEEP • Architectural decisions 6. CORBA IIOP affect one another 7. … Rationale 7.10.2008 SOA Symposium 2008, Amsterdam 11 ©2008 Cesare Pautasso
  13. 13. Application Integration Styles Shared Remote Message Bus File Database Procedure Transfer Call REST WS-* Integration Technology Platform 7.10.2008 SOA Symposium 2008, Amsterdam 12 ©2008 Cesare Pautasso
  14. 14. Related Decisions (WS-*) Shared Remote Message Bus File Database Procedure Transfer Call REST WS-* 7.10.2008 SOA Symposium 2008, Amsterdam 13 ©2008 Cesare Pautasso
  15. 15. Related Decisions (RPC) Shared Remote Message Bus File Database Procedure Transfer Call REST WS-* 7.10.2008 SOA Symposium 2008, Amsterdam 14 ©2008 Cesare Pautasso
  16. 16. Decision Space Overview 7.10.2008 SOA Symposium 2008, Amsterdam 15 ©2008 Cesare Pautasso
  17. 17. 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.10.2008 SOA Symposium 2008, Amsterdam 16 ©2008 Cesare Pautasso
  18. 18. Architectural Principles 1. Protocol Layering • HTTP = Application-level Protocol (REST) • HTTP = Transport-level Protocol (WS-*) 2. Dealing with Heterogeneity 3. Loose Coupling 7.10.2008 SOA Symposium 2008, Amsterdam 17 ©2008 Cesare Pautasso
  19. 19. RESTful Web Service Example HTTP Client Web Server Database (Web Browser) SELECT * GET /book?ISBN=222 FROM books WHERE isbn=222 POST /order INSERT INTO orders 301 Location: /order/612 PUT /order/612 UPDATE orders WHERE id=612 7.10.2008 SOA Symposium 2008, Amsterdam 18 ©2008 Cesare Pautasso
  20. 20. Big Web Service Example (from REST perspective) Web Service HTTP Client Web Server Implementation (Stub Object) POST /soap/endpoint return getBook(222) POST /soap/endpoint return new Order() POST /soap/endpoint order.setCustomer(x) 7.10.2008 SOA Symposium 2008, Amsterdam 19 ©2008 Cesare Pautasso
  21. 21. Protocol Layering • “The Web is the universe of globally • “The Web is the universal (tunneling) accessible information” transport for messages” (Tim Berners Lee) – Applications get a chance to – Applications should publish their interact but they remain data on the Web (through URI) “outside of the Web” POX RSS JSON … SOAP (WS-*) HTTP HTTP HTTP HTTP HTTP SMTP MQ… GET POST PUT DEL POST Resource URI Endpoint URI Application Application 7.10.2008 SOA Symposium 2008, Amsterdam 20 ©2008 Cesare Pautasso
  22. 22. Dealing with Heterogeneity • Web Applications • Enterprise Computing Picture from Eric Newcomer, IONA HTTP CICS IMS 7.10.2008 SOA Symposium 2008, Amsterdam 21 ©2008 Cesare Pautasso
  23. 23. Conceptual Comparison Note: this table will scroll up during the talk 7.10.2008 SOA Symposium 2008, Amsterdam 22 ©2008 Cesare Pautasso
  24. 24. Technology Comparison Note: this table will scroll up during the talk 7.10.2008 SOA Symposium 2008, Amsterdam 23 ©2008 Cesare Pautasso
  25. 25. 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 REST WS-* Decisions 17 14 Alternatives 27 35 Decisions with 1 or more alternative options 7.10.2008 SOA Symposium 2008, Amsterdam 24 ©2008 Cesare Pautasso
  26. 26. Measuring Complexity REST WS-* Decisions 5 12 Alternatives 16 32 Decisions with more than 1 alternative options REST WS-* Decisions 17 14 Alternatives 27 35 Decisions with 1 or more alternative options 7.10.2008 SOA Symposium 2008, Amsterdam 25 ©2008 Cesare Pautasso
  27. 27. Measuring Complexity REST WS-* Decisions 5 12 Alternatives 16 32 Decisions with more than 1 alternative options • URI Design • Resource Interaction Semantics • Payload Format • Service Description • Service Composition 7.10.2008 SOA Symposium 2008, Amsterdam 26 ©2008 Cesare Pautasso
  28. 28. Measuring Complexity REST WS-* Decisions 5 12 Alternatives 16 32 Decisions with more than 1 alternative options REST WS-* Decisions 12 2 Decisions with only 1 alternative option 7.10.2008 SOA Symposium 2008, Amsterdam 27 ©2008 Cesare Pautasso
  29. 29. Measuring Complexity • Payload Format • Data Representation Modeling REST WS-* Decisions 12 2 Decisions with only 1 alternative option 7.10.2008 SOA Symposium 2008, Amsterdam 28 ©2008 Cesare Pautasso
  30. 30. Measuring Effort REST WS-* Do-it-yourself 5 0 Alternatives Decisions with only do-it-yourself alternatives REST WS-* Decisions 12 2 Decisions with only 1 alternative option 7.10.2008 SOA Symposium 2008, Amsterdam 29 ©2008 Cesare Pautasso
  31. 31. Measuring Effort REST WS-* Do-it-yourself 5 0 Alternatives Decisions with only do-it-yourself alternatives • Resource Identification • Resource Relationship • Reliability • Transactions • Service Discovery 7.10.2008 SOA Symposium 2008, Amsterdam 30 ©2008 Cesare Pautasso
  32. 32. Freedom of Choice Freedom from Choice 7.10.2008 SOA Symposium 2008, Amsterdam 31 ©2008 Cesare Pautasso
  33. 33. 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) 7.10.2008 SOA Symposium 2008, Amsterdam 32 ©2008 Cesare Pautasso
  34. 34. 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. 7.10.2008 SOA Symposium 2008, Amsterdam 33 ©2008 Cesare Pautasso
  35. 35. 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 In: Proceedings of the 5th VLDB Workshop on Technologies for E-Services (TES-04), Toronto, Canada, August 29- 30, 2004. 7.10.2008 SOA Symposium 2008, Amsterdam 34 ©2008 Cesare Pautasso
  36. 36. 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 SOA Symposium 2008, Amsterdam 35 ©2008 Cesare Pautasso
  37. 37. Backup Material on REST Cesare Pautasso Faculty of Informatics University of Lugano (USI), Switzerland http://www.pautasso.info 7.10.2008 SOA Symposium 2008, Amsterdam 36 ©2008 Cesare Pautasso
  38. 38. 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. Resource Identification through URI 2. 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 representations 4. Hyperlinks to define relationships between resources and valid state transitions of the service interaction 7.10.2008 SOA Symposium 2008, Amsterdam 37 ©2008 Cesare Pautasso
  39. 39. URI: Uniform Resource Identifier • 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 Query Fragment • REST advocates the use of “nice” URIs • In most HTTP stacks URIs cannot have arbitrary length (4Kb) 7.10.2008 SOA Symposium 2008, Amsterdam 38 ©2008 Cesare Pautasso
  40. 40. What is a “nice” URI? Prefer Nouns to Verbs http://map.search.ch/lugano Keep them Short http://maps.google.com/lugano http://maps.google.com/maps?f=q&hl=en&q=lugano, +switzerland&layer=&ie=UTF8&z=12&om=1&iwloc=addr 7.10.2008 SOA Symposium 2008, Amsterdam 39 ©2008 Cesare Pautasso
  41. 41. Uniform Interface Principle (CRUD Example) CRUD REST Initialize the state of a CREATE POST/PUT new resource at the given URI Retrieve the current READ GET state of the resource Modify the state UPDATE PUT of a resource Clear a resource, DELETE DELETE after the URI is no longer valid 7.10.2008 SOA Symposium 2008, Amsterdam 40 ©2008 Cesare Pautasso
  42. 42. POST vs. GET • GET is a read-only operation. 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. Web browsers warn you when refreshing a page generated with POST 7.10.2008 SOA Symposium 2008, Amsterdam 41 ©2008 Cesare Pautasso
  43. 43. RESTful Web Services Design 1. Identify resources to be exposed as DELETE services (e.g., yearly risk report, book POST catalog, purchase order, open bugs) GET PUT 2. Define “nice” URLs to address them 3. Understand what it means to do a GET, /loan POST, PUT, DELETE on a given resource URI /balance X X X 4. Design and document resource /client ? representations (payload formats) 5. Model relationships (e.g., containment, /book reference, state transitions) between /order ? ? resources with hyperlinks that can be followed to get more details 6. Implement and deploy on Web server /soap X X X 7. Test with a Web browser 7.10.2008 SOA Symposium 2008, Amsterdam 42 ©2008 Cesare Pautasso
  44. 44. Resource Representation Formats: XML vs JSON • XML • JavaScript Object Notation (JSON) – PO-XML • Wire format introduced for AJAX – SOAP (WS-*) Web applications (Browser- – RSS, ATOM Web Server communication) • Standard textual syntax for • Textual syntax for serialization of semi-structured data non-recurrent data structures • Many tools available: • Supported in most languages XML Schema, DOM, SAX, XPath, (not only JavaScript) XSLT, XQuery • Not extensible • Everyone can parse it (does not need to be) (not necessarily understand it) • “JSON has become the X in Ajax” • Slow and Verbose 7.10.2008 SOA Symposium 2008, Amsterdam 43 ©2008 Cesare Pautasso

×