Published on

8.4.2011, FUB Bern

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. SOA with REST Prof. Cesare Pautasso Faculty of InformaticsUniversity of Lugano, Switzerland Lugano htt // t i f @pautasso
  2. 2. About Cesare Pautasso • Assistant Professor at the Faculty of Informatics, University of Lugano, Switzerland y g • Research Projects: • SOSOA – Self-Organizing Service Oriented Architectures • CLAVOS – Continuous Lifelong Analysis and Verification of Open Services • BPEL for REST, RESTful Atomic Transactions with TCC • SAW - Software Architecture Warehouse • Researcher at IBM Zurich Research Lab (2007) • Post-Doc at ETH Zürich • Software: JOpera: Process Support for more than Web services • Ph.D. at ETH Zürich, S t e a d (2004) ü c , Switzerland ( 00 ) • Laurea Politecnico di Milano (2000) • Representations: http://www pautasso info/ (Web) (Twitter Feed)©2011 Cesare Pautasso 2
  3. 3. Outline  REST vs. WS-*  Architectural Styles  SOA Quality Attributes  What is REST?  The Web as a new Software Connector for SOA  Example: Tunneling or Publishing on the Web?  SOA with REST©2010 - Cesare Pautasso 3
  4. 4. SOA REST©2010 - Cesare Pautasso 4
  5. 5. RESTful Service Web Services Oriented Architectures c tectu es WS-* Web Services©2010 - Cesare Pautasso 5
  6. 6. WS-* Standards Stack©2011 - Cesare Pautasso 7
  7. 7. 8 Stat S e Management Messaging Transacti ions Se rity ecurWS-* Standards Stack BPM Re eliability Meta ta M adat ©2011 - Cesare Pautasso Int oper lity tero rabi
  8. 8. RESTful Services Standards AtomPub RSS Atom XML JSON URI HTTP MIME SSL/TLS©2011 - Cesare Pautasso 9
  9. 9. Service Oriented Architectural Style?©2010 - R. Peisl, 2006From Cesare Pautasso 10
  10. 10. SOA Quality Attributes  Interoperability  Modifiability  Integrability  Reuse   Portability Reliability R li bili SOA  Security  Efficiency  Business Flexibility/Agility  Return on Investment©2010 - Cesare Pautasso 11
  11. 11. REST Constraints in one slide  Web Services expose their data and functionality trough y g PUT resources identified by URI R  Uniform Interface: GET Clients perform stateless POST interactions with resources DELETE through a fix set of verbs. Example HTTP: GET (read), PUT (update), DELETE, POST (catch all),  Multiple representations for the same resource  Hyperlinks model resource relationships and valid state transitions for dynamic protocol description and discovery©2010 - Cesare Pautasso 12
  12. 12. Is REST really used? Atom, 2% Gdata, 1% Gd 1% XMPP, 0% JavaScript, 6% XML‐RPC, 2% SOAP, 17% JSON‐RPC, 0% SMS,  SMS 3120 APIs 0% RSS, 1% 1.4.2011 REST,  71%©2010 - Cesare Pautasso 13
  13. 13. Design Methodology for REST 1. Identify resources to be exposed as services (e.g., yearly risk report, book DE catalog, catalog purchase order, open bugs, order bugs ELETE POST blog entries, polls and votes) GET PUT 2. Model relationships (e.g., containment, reference, reference state transitions) between /loan     resources with hyperlinks that can be followed to get more details (or perform /balance     state transitions) /client / li t     3. Define URIs to address the resources 4. Understand what it means to do a GET, /book     POST, PUT, POST PUT DELETE for each resource (and whether it is allowed or not) /order  ?   5. Design, document and standardize resource representations (media types) 6. Implement and deploy on Web server /soap     7. Test with a Web browser©2010 - Cesare Pautasso 14
  14. 14. Design Space M Representations (Variable)©2010 - Cesare Pautasso 15
  15. 15. Simple Doodle API Example Design 1. Resources: DELE polls and votes PO 2. 2 Containment Relationship: GET G OST PUT P ETE poll /poll     {id1} /poll/{id}     vote /p /{ }/ /poll/{id}/vote     {id4} /poll/{id}/vote/{id}    ? {id5} 3. URIs embed IDs of “child” instance resources 4. POST on the container is used to {id2} create child resources 5. PUT/DELETE for updating and {id3} removing child resources©2010 - Cesare Pautasso 16
  16. 16. Simple Doodle API Example 1. Creating a poll (transfer the state of a new poll on the Doodle service) /poll /poll/090331x /poll/090331x/vote p POST /poll GET /poll/090331x G / ll/090331 <options>A,B,C</options> 200 OK 201 Created <options>A,B,C</options> Location: /poll/090331x <votes href=“/vote”/> 2. Reading a poll (transfer the state of the poll from the Doodle service) (t f th t t f th ll f th D dl i )©2010 - Cesare Pautasso 17
  17. 17. Simple Doodle API Example  Participating in a poll by creating a new vote sub-resource /poll /poll/090331x /poll/090331x/vote /p /poll/090331x/vote/1 / / / POST /poll/090331x/vote GET /poll/090331x G / ll/090331 <name>C. Pautasso</name> <choice>B</choice> 200 OK <options>A,B,C</options> 201 Created <votes><vote id=“1”> Location: i <name>C. Pautasso</name> C P t / /poll/090331x/vote/1 <choice>B</choice> </vote></votes>©2010 - Cesare Pautasso 18
  18. 18. Simple Doodle API Example  Existing votes can be updated (access control headers not shown) /poll /poll/090331x /poll/090331x/vote /p /poll/090331x/vote/1 / / / PUT /poll/090331x/vote/1 GET /poll/090331x G / ll/090331 <name>C. Pautasso</name> <choice>C</choice> 200 OK <options>A,B,C</options> 200 OK <votes><vote id=“/1”> <name>C. Pautasso</name> C P t / <choice>C</choice> </vote></votes>©2010 - Cesare Pautasso 19
  19. 19. Simple Doodle API Example  Polls can be deleted once a decision has been made /poll /poll/090331x /poll/090331x/vote /p /poll/090331x/vote/1 / / / DELETE /poll/090331x GET /poll/090331x G / ll/090331 200 OK 404 Not Found©2010 - Cesare Pautasso 20
  20. 20. The End to End View R GET C A B PUT GET  The resource acts as an communication medium that allows services to exchange representations of their state  This is not equivalent to sending and receiving messages from a bus©2011 - Cesare Pautasso 21
  21. 21. Real Doodle Demo • Info on the real Doodle API: • Lightweight demo with Poster Firefox Extension:©2010 - Cesare Pautasso 22
  22. 22. Software Connectors File Transfer Fil T f Shared Data Procedure Call Remote Procedure Call Message Bus Events©2010 - Cesare Pautasso 23
  23. 23. What is your SOA connector today? RPC BUS REST/HTTP©2010 - Cesare Pautasso 24
  24. 24. REST as a new connector RPC BUS Publish/Subscribe Call REST/HTTP Get/Put/Post/Delete©2010 - Cesare Pautasso 25
  25. 25. Richardson Maturity Model 0. HTTP as an RPC Protocol ( (Tunnel POST+POX or POST+JSON) ) I. Multiple Resource URIs (Fine Grained (Fine-Grained Global Addressability) II. Uniform HTTP Verbs (Contract Standardization) III. Hypermedia (Protocol Discoverability)  A REST API needs to include levels I, II, III  Most “RESTful” APIs don’t RESTful don t©2011 - Cesare Pautasso 26
  26. 26. Antipatterns - REST vs. HTTP REST HTTP “RPC” RESTful HTTP©2010 - Cesare Pautasso 27
  27. 27. Antipatterns – HTTP as a tunnel  Tunnel through one HTTP Method GET / i? th d ddC t /api?method=addCustomer&name=Pautasso & P t GET /api?method=deleteCustomer&id=42 GET /api?method=getCustomerName&id=42 GET /api?method=findCustomers&name=Pautasso*  E Everything through GET hi h h • Advantage: Easy to test from a Browser address bar (the “action” is represented in the resource URI) action • Problem: GET should only be used for read-only ( (= idempotent and safe) requests. p ) q What happens if you bookmark one of those links? • Limitation: Requests can only send up to approx. 4KB of data (414 R Request-URI Too Long) t URI T L )©2010 - Cesare Pautasso 28
  28. 28. Antipatterns – HTTP as a tunnel  Tunnel through one HTTP Method  Everything through POST • Advantage: Can upload/download an arbitrary amount of data (this is what SOAP or XML-RPC do) • P bl Problem: POST is not id i t idempotent and i unsafe (cannot cache) t t d is f ( t h ) POST /service/endpoint <soap:Envelope> <soap:Body> <findCustomers> <name>Pautasso*</name> </findCustomers> </soap:Body> </soap:Envelope>©2010 - Cesare Pautasso 29
  29. 29. Web Sites (1992) Web HTML Web Browser HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server (HTTP)©2011 - Cesare Pautasso 30
  30. 30. RESTful Web Services (2007) PO-X RSS/A JSO WADL ON XML Atom Web Client HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server (HTTP)©2011 - Cesare Pautasso 31
  31. 31. RESTful Web Service Example Web Server HTTP Client Database D t b Application Server (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 id 612©2011 - Cesare Pautasso 32
  32. 32. WS-* Service Example(from REST perspective)(f ti ) Web Server Web Service HTTP Client Application Server Implementation (Stub Object) POST /soap/endpoint return getBook(222) POST /soap/endpoint return new Order() POST /soap/endpoint order.setCustomer(x)©2011 - Cesare Pautasso 33
  33. 33. Protocol Layering “The Web is the universe of “The Web is the universal globally accessible information” (tunneling) transport for (Tim Berners Lee) messages messages”  Applications should publish  Applications get a chance their data on the Web to interact but they remain (through URI) “outside of the Web” outside Web AtomPub JSON POX … SOAP (WS ) (WS-*) HTTP HTTP HTTP HTTP HTTP SMTP MQ… MQ GET POST PUT DEL POST (Many) Resource URI 1 Endpoint URI Application pp Application pp©2011 - Cesare Pautasso 34
  34. 34. Dealing with Heterogeneity  Enable Cooperation  Enable Integration  Web Applications  Enterprise Architectures te p se c tectu es Picture from Eric Newcom IONA HTTP mer, CICS IMS©2011 - Cesare Pautasso 35
  35. 35. Heterogeneity Web Enterprise Applications Architectures REST WS WS-*©2011 - Cesare Pautasso 36
  36. 36. Heterogeneity Web Enterprise Applications Architectures REST Claim: REST can also be successfully used to design integrated enterprise applications t d i i t t d t i li ti©2011 - Cesare Pautasso 37
  37. 37. Enterprise “Use Cases” Enterprise E t i Architectures CRUD Services Web-friendly APIs Real-time Services Mobile Services M bil S i Transactional Services Composite Services©2011 - Cesare Pautasso 38
  38. 38. Enterprise “Use Cases” Enterprise E t i Architectures WS WS-* REST Part f th d b t i b t h P t of the debate is about how many “enterprise” use cases can be covered with REST as opposed to WS-*©2011 - Cesare Pautasso 39
  39. 39. SOA Quality Attributes & REST Constraints  Interoperability  Content Negotiation  Modifiability  Uniform Interface  Integrability  Statelessness  Reuse Interactions    Portability Reliability Security SOA with REST  Caching  Global Addressability Addressabilit  Efficiency  Hypermedia  Business  Middleware Flexibility/Agility Intermediaries ( o es Gate ays) (Proxies & Gateways)  Return on Investment  Lightweight frameworks©2010 - Cesare Pautasso 40
  40. 40. 41 Stat S e itManagement with REST? Can you do Messaging Transacti ions Se rity ecurBPM Re eliability Meta ta M adat ©2010 - Cesare PautassoInt oper lity tero rabi
  41. 41. Business Process Management Workflow Workflow Process Model Users/Clients Participants Act 2 Act 4 Act 1 Act 5 Act 7 Act 3 Act 6 RESTful Workflow Management Engine PUT GET R Adapters Bus Applications Web W b Services POST DELETE Databases©2010 - Cesare Pautasso 42
  42. 42. BPM with REST Process Model Publishing Act 2 Act 4 R Processes P Act 1 Act 5 Act 7 as Resources Act 3 Act 6 RESTful Workflow Management Engine RESTful Service R R R Composition©2010 - Cesare Pautasso 43
  43. 43. REST Transactions: The Problem PUT  Persistent GET R RESTful Web Service Storage POST DELETE Backend 1  PUT S RESTful Web Service Backend 2 GET POST Database 3 DELETE Adapted from Stefan Tilkov, Using REST for SOA, QCon SFO 2010©2010 - Cesare Pautasso 44
  44. 44. Conclusions SOA comes from the business IT domain, while REST comes from the World Wide Web. REST is more at home with HTTP and HTML while SOA is HTML, more at home with SOAP and WSDL. Some REST advocates see the Web Services stack both as begin synonymous with SOA and as an invader in the architecture of the "real" Web. Some SOA advocates see REST as an unnecessary diversion from ensuring connectivity between enterprise service bus technologies supplied by different vendors. Despite their different histories, REST and SOA can learn a lot from each other. SOA with REST aims to forge an effective architectural model both for enterprise computing and for computing on the World Wide Web that brings the best of both worlds together©2010 - Cesare Pautasso 45
  45. 45. References  R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, PhD Thesis, University of California, Irvine, 2000  C Pautasso O. Zimmermann, F. Leymann RESTful Web Services vs. Big C. Pautasso, O Zimmermann F Leymann, vs Web Services: Making the Right Architectural Decision, Proc. of the 17th International World Wide Web Conference (WWW2008), Bejing, China, April 2008  C. Pautasso, BPEL for REST, Proc. of the 7th International Conference on Business Process Management (BPM 2008), Milano, Italy, Sept. 2008  C. Pautasso, Composing RESTful Services with JOpera, In: Proc. of the International Conference on Software Composition (SC2009), July 2009, Zurich, Switzerland.  C. Pautasso and E. Wilde, Why is the Web Loosely Coupled? A Multi- Faceted Metric for Service Design, In: Proc. of the 18th International World Wide Web Conference (WWW2009), Madrid, Spain, April 2009  G. Pardon, C. Pautasso, Towards Distributed Atomic Transactions over RESTful S S f Services, In: REST: From Research to Practice, S S Springer, 2011 ISBN 978-1-4419-8302-2© 46
  46. 46. SOA with REST Raj Balasubramanian, Benjamin Carlyle Carlyle, Thomas Erl, Cesare Pautasso, SOA with REST, ith REST Prentice Hall, to appear in 2011 pp©2010 - Cesare Pautasso 47
  47. 47. p // g/ / SOA with REST Prof. Cesare Pautasso Faculty of Informatics University of Lugano Switzerland Lugano, htt // t i f @pautasso
  48. 48. ©2010 Cesare Pautasso 49