Contenu connexe Similaire à Cesare Pautasso R E S T V1 Similaire à Cesare Pautasso R E S T V1 (20) Plus de SOA Symposium (20) Cesare Pautasso R E S T V11. 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. 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. 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. 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. 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. 7.10.2008 SOA Symposium 2008, Amsterdam 5
©2008 Cesare Pautasso
7. RESTful
RSS
XML JSON
MIME
URI HTTP
SSL
7.10.2008 SOA Symposium 2008, Amsterdam 6
©2008 Cesare Pautasso
8. Is REST being used?
Slide from Paul Downey, BT
7.10.2008 SOA Symposium 2008, Amsterdam 7
©2008 Cesare Pautasso
9. Can we really compare
WS-* vs. REST?
WS-* REST
7.10.2008 SOA Symposium 2008, Amsterdam 8
©2008 Cesare Pautasso
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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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. 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. Conceptual Comparison
Note: this table
will scroll up
during the talk
7.10.2008 SOA Symposium 2008, Amsterdam 22
©2008 Cesare Pautasso
24. Technology Comparison
Note: this table
will scroll up
during the talk
7.10.2008 SOA Symposium 2008, Amsterdam 23
©2008 Cesare Pautasso
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. 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. 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. 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. 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. 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. 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. Freedom of Choice
Freedom from Choice
7.10.2008 SOA Symposium 2008, Amsterdam 31
©2008 Cesare Pautasso
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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