Take a REST

Transcript

1. Take a REST! Cyril ROHR, MYRIADS - INRIA 04/10/2010 Building better distributed applications by embracing the architecture of the Web Monday, 13 February 2012
2. Agenda 1. Distributed applications 2. Styles for Service Oriented Architectures A. WS-* B. REST 3. Quality of service 4. Conclusion Monday, 13 February 2012
3. 1. Distributed Applications Monday, 13 February 2012
4. Objectives Integration across application boundaries Monday, 13 February 2012
5. Objectives Integration across organizational boundaries Monday, 13 February 2012
6. Evolution APPLICATION 1 APPLICATION 2 APPLICATION 3 GUI LOGIC DATA Monolithic applications • duplication • maintenance cost • no data sharing Monday, 13 February 2012
7. Evolution Applications sharing data • duplication • fragile Monday, 13 February 2012
8. Evolution Applications sharing objects over the network • looks great! Monday, 13 February 2012
9. Evolution Applications sharing objects over the network • tight coupling • complex • vendor lock-in Monday, 13 February 2012
10. Evolution Service Oriented Architectures • loose-coupling • language independence • reusability • composability Monday, 13 February 2012
11. Great Monday, 13 February 2012
12. 2. Styles e-potpourri.com Monday, 13 February 2012
13. • WS-* (SOAP/WSDL) • REST (HTTP) Styles for Service Oriented Architectures http://www.oasis-open.org/ http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Monday, 13 February 2012
14. WS-* Monday, 13 February 2012
15. WS-* Monday, 13 February 2012
16. WS-* Monday, 13 February 2012
17. WS-* • Pros • Apparent simplicity • Kind-of standardized, somewhat good interoperability Monday, 13 February 2012
18. • Cons • Complex specs, (recent versions) not used WSDL1.1 not a standard. Nobody uses WSDL2. • Vendor lock-in • Requires IDE to do the simplest things • Went from message- oriented to RPC style ➡ Tight coupling (generated stubs) • UDDI is a failure WS-Security, WS-Policy, WS-SecurityPolicy, WS-PolicyAssertions, WS- PolicyAttachment, WS-Trust, WS-Privacy, WS-Routing, WS-Referral, WS- Coordination, WS-Transaction, WS-SecureConversation, WS-Federation, WS-Authorization, WS-Attachments, WS-Transfer, WS-ResourceTransfer, WS-ReliableMessaging, WS-Addressing, WS-Agreement... WS-* Monday, 13 February 2012
19. WS-* Monday, 13 February 2012
20. WS-* Protocol independence is a failure, everything is tunneled over HTTP Monday, 13 February 2012
21. WS-* Protocol independence is a failure, everything is tunneled over HTTP SOAP Envelope SOAP Header SOAP Body Monday, 13 February 2012
22. WS-* Protocol independence is a failure, everything is tunneled over HTTP SOAP Envelope SOAP Header SOAP Body HTTP Message HTTP Header HTTP Body Monday, 13 February 2012
23. WS-* Protocol independence is a failure, everything is tunneled over HTTP SOAP Envelope SOAP Header SOAP Body HTTP Message HTTP Header HTTP Body HTTP Message HTTP Header Body SOAP Envelope SOAP Header SOAP Body Monday, 13 February 2012
24. WS-* Protocol independence is a failure, everything is tunneled over HTTP SOAP Envelope SOAP Header SOAP Body HTTP Message HTTP Header HTTP Body HTTP Message HTTP Header Body SOAP Envelope SOAP Header SOAP Body ? Monday, 13 February 2012
25. Well... Monday, 13 February 2012
26. REST The REST Web is the subset of the WWW (based on HTTP) in which agents provide uniform interface semantics – essentially create (POST), retrieve (GET), update (PUT) and delete (DELETE) – rather than arbitrary or application-specific interfaces, and manipulate resources only by the exchange of representations. Furthermore, the REST interactions are ”stateless” in the sense that the meaning of a message does not depend on the state of the conversation. W3C Monday, 13 February 2012
27. REST The REST Web is the subset of the WWW (based on HTTP) in which agents provide uniform interface semantics – essentially create (POST), retrieve (GET), update (PUT) and delete (DELETE) – rather than arbitrary or application-specific interfaces, and manipulate resources only by the exchange of representations. Furthermore, the REST interactions are ”stateless” in the sense that the meaning of a message does not depend on the state of the conversation. W3C • HTTP as an application protocol • Uniform Interface • Stateless interactions Monday, 13 February 2012
28. HTTP Monday, 13 February 2012
29. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> Monday, 13 February 2012
30. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> Request Monday, 13 February 2012
31. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> Request Response Monday, 13 February 2012
32. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method Request Response Monday, 13 February 2012
33. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI Request Response Monday, 13 February 2012
34. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI headers Request Response Monday, 13 February 2012
35. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI headers Request Response status Monday, 13 February 2012
36. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI headers Request Response status headers Monday, 13 February 2012
37. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI headers Request Response status headers body Monday, 13 February 2012
38. HTTP GET /my-resource-uri HTTP/1.1 Host: example.com Accept: application/xml HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 <element> ... </element> method URI headers Request Response status headers body • A restricted set of standardized methods GET, POST, PUT, DELETE, MOVE, COPY, HEAD, OPTIONS... • A restricted set of standardized status codes 200, 201, 404, 500... Monday, 13 February 2012
39. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Monday, 13 February 2012
40. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages http://example.com/orders?year=2008 http://example.com/customers/1234 http://example.com/orders/2007/10/776654 http://example.com/products/4554 A resource can be anything that has identity (RFC 2396) URI Monday, 13 February 2012
41. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Request Response Request Response Monday, 13 February 2012
42. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages GET /events/1234 Host: example.com Accept: application/vnd.mycompany.event+xml ... <event>...</event> Request Response Request Response Monday, 13 February 2012
43. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages GET /events/1234 Host: example.com Accept: application/vnd.mycompany.event+xml ... <event>...</event> GET /events/1234 Host: example.com Accept: text/calendar ... BEGIN:VCALENDAR ... END:VCALENDAR Request Response Request Response Monday, 13 February 2012
44. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages GET /events/1234 Host: example.com Accept: application/vnd.mycompany.event+xml ... <event>...</event> GET /events/1234 Host: example.com Accept: text/calendar ... BEGIN:VCALENDAR ... END:VCALENDAR Media-Types with semantics Request Response Request Response Monday, 13 February 2012
45. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages GET /events/1234 HTTP/1.1 Host: example.com Accept: application/vnd.mycompany.event+xml HTTP/1.1 200 OK Content-Type: application/vnd.mycompany.event+xml Content-Length: 334 <event> <title>Take a REST!</title> <date>2010-10-04T12:00:00Z</date> <links> <link rel=”self” ref=”http://example.com/events/1234” /> <link rel=”author” ref=”http://crohr.myopenid.com/” /> <link rel=”location” ref=”http://maps.google.com/maps? ll=48.117288,-1.639538” /> <link rel=”next” ref=”http://example.com/events/1235” /> <link rel=”subscribe” ref=”http://example.com/events/1234/ subscriptions” /> </links> </event> Transition between services Monday, 13 February 2012
46. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages GET /events/1234 HTTP/1.1 Host: example.com Accept: application/vnd.mycompany.event+xml HTTP/1.1 200 OK Content-Type: application/vnd.mycompany.event+xml Content-Length: 334 <event> <title>Take a REST!</title> <date>2010-10-04T12:00:00Z</date> <links> <link rel=”self” ref=”http://example.com/events/1234” /> <link rel=”author” ref=”http://crohr.myopenid.com/” /> <link rel=”location” ref=”http://maps.google.com/maps? ll=48.117288,-1.639538” /> <link rel=”next” ref=”http://example.com/events/1235” /> <link rel=”subscribe” ref=”http://example.com/events/1234/ subscriptions” /> </links> </event> Transition between services Monday, 13 February 2012
47. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Client acts as a state machine: it transitions from state to state via hyperlinks until it reaches the final (objective) state. Client must know a priori about the media-types of the services. Monday, 13 February 2012
48. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Separation of control from data allows for a layered architecture by introducing intermediaries GET /uri HTTP/1.1 Host: example.com Accept: application/xml Cache-Control: max-age=60 HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 Cache-Control: public, max-age=600 <element> ... </element> method URI headers Request Response status headers body Monday, 13 February 2012
49. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Separation of control from data allows for a layered architecture by introducing intermediaries GET /uri HTTP/1.1 Host: example.com Accept: application/xml Cache-Control: max-age=60 HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 Cache-Control: public, max-age=600 <element> ... </element> method URI headers Request Response status headers body Client Server Monday, 13 February 2012
50. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Separation of control from data allows for a layered architecture by introducing intermediaries GET /uri HTTP/1.1 Host: example.com Accept: application/xml Cache-Control: max-age=60 HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 Cache-Control: public, max-age=600 <element> ... </element> method URI headers Request Response status headers body Client Server proxy Monday, 13 February 2012
51. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Separation of control from data allows for a layered architecture by introducing intermediaries GET /uri HTTP/1.1 Host: example.com Accept: application/xml Cache-Control: max-age=60 HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 Cache-Control: public, max-age=600 <element> ... </element> method URI headers Request Response status headers body Client Server cache proxy Monday, 13 February 2012
52. The REST Uniform Interface Identification of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Separation of control from data allows for a layered architecture by introducing intermediaries GET /uri HTTP/1.1 Host: example.com Accept: application/xml Cache-Control: max-age=60 HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 334 Cache-Control: public, max-age=600 <element> ... </element> method URI headers Request Response status headers body Client Server cache load-balancer proxy Monday, 13 February 2012
53. Claim RESTful HTTP moves you closer to SOA goals than WS-* Stefan Tilkov Monday, 13 February 2012
54. • Addressability Each resource is uniquely identified. • Interoperability The only thing that changes is the name of resources. Available HTTP verbs, status codes, etc. are standardized. “Given a URI, anyone already knows how to access it”. • Ubiquity Every programming language knows how to speak HTTP. A large base of existing tools (browser, command-line tools...) • Control meta-data (HTTP headers). • Layered architecture: push non-functional requirements into intermediaries. REST Monday, 13 February 2012
55. OK, but what about... Monday, 13 February 2012
56. 3. Quality of Service Monday, 13 February 2012
57. Claim Advanced WS-* standards are overrated Stefan Tilkov Monday, 13 February 2012
58. Security • WS-*: WS-Security • REST: HTTP + SSL/TLS is sufficient in 99% of cases. Message-based security is way too expensive. Monday, 13 February 2012
59. Scalability • REST: constraint of statelessness means that requests are not bound to a specific server. Per-URI (service) policies can be applied. Load- Balancer Client serverA/service1 serverB/service1 serverC/service1 Monday, 13 February 2012
60. • GET » POST, PUT, DELETE GET is safe, idempotent, and thus cacheable • WS-*: tunneling over HTTP POST POST is not safe, not idempotent, and thus not cacheable Load- Balancer Client serverA/service1 serverB/service1 serverC/service1 Cache Cache-Control: public, max-age=600 Scalability Monday, 13 February 2012
61. Fault Tolerance Load- Balancer Client serverA/service1 serverB/service1 serverC/service1 500 Internal Server Error ... 200 OK ... • REST Uniform Interface allows intermediaries to take decisions 200 OK ... Monday, 13 February 2012
62. Management / Auditing WS-*: Web Services for Distributed Management (WSDM) ? REST: intermediaries have plenty of logs about your services, and load-balancers can regularly check specific resources and report errors. 21/Apr/2010 14:55:39] "POST /endpoint" 500 140 0.035 21/Apr/2010 14:55:38] "POST /endpoint" 200 320 0.115 21/Apr/2010 14:55:40] "POST /endpoint" 200 187 0.107 21/Apr/2010 14:55:40] "POST /endpoint" 200 265 0.145 [21/Apr/2010 14:55:38] "GET /events/1234" 500 78 0.0202 [21/Apr/2010 14:55:39] "GET /events/1234" 200 354 0.0 [21/Apr/2010 14:55:40] "POST /events" 201 387 0.120 [21/Apr/2010 14:55:42] "DELETE /events/1234" 204 187 0.070 Load- Balancer Client serverA/service1 serverB/service1 serverC/service1 Monday, 13 February 2012
63. Service discovery • WS-*: UDDI (centralized) • REST: link relationships (distributed) Monday, 13 February 2012
64. Reliability • WS-*: WS-ReliableMessaging • REST: reliable messaging should be done at the business level, not at the message level. http://www.infoq.com/articles/no-reliable-messaging Monday, 13 February 2012
65. Transactions • WS-*: WS-Transaction • REST: you don’t. Transactions have no sense in distributed and unreliable environments. Put them behind a service. Client Transactional Service Monday, 13 February 2012
66. Service Level Agreement? • WS-*: WS-Agreement • REST: intelligent use of HTTP Monday, 13 February 2012
67. RESTful SLA negotiation Client serverA service1 serverB service1 serverC service1 OPTIONS /service-uri Solution 1: Client asks for details about each service, and make a choice Monday, 13 February 2012
68. RESTful SLA negotiation Client serverA service1 serverB service1 serverC service1 OPTIONS /service-uri OPTIONS /billings HTTP/1.1 Host: example1.com HTTP/1.1 200 OK Allow: GET, HEAD, POST X-SLA-Control: max-execution-time=1.3, max-execution-cost=0.2, penalty=1 Link: http://example1.com/sla.xml;type=application/xml A Solution 1: Client asks for details about each service, and make a choice Monday, 13 February 2012
69. RESTful SLA negotiation Client serverA service1 serverB service1 serverC service1 OPTIONS /service-uri OPTIONS /billings HTTP/1.1 Host: example1.com HTTP/1.1 200 OK Allow: GET, HEAD, POST X-SLA-Control: max-execution-time=1.3, max-execution-cost=0.2, penalty=1 Link: http://example1.com/sla.xml;type=application/xml A OPTIONS /billings HTTP/1.1 Host: example2.com ... X-SLA-Control: max-execution-time=0.9, max-execution-cost=0.4, penalty=0.8 B Solution 1: Client asks for details about each service, and make a choice Monday, 13 February 2012
70. RESTful SLA negotiation Client serverA service1 serverB service1 serverC service1 OPTIONS /service-uri OPTIONS /billings HTTP/1.1 Host: example1.com HTTP/1.1 200 OK Allow: GET, HEAD, POST X-SLA-Control: max-execution-time=1.3, max-execution-cost=0.2, penalty=1 Link: http://example1.com/sla.xml;type=application/xml A OPTIONS /billings HTTP/1.1 Host: example2.com ... X-SLA-Control: max-execution-time=0.9, max-execution-cost=0.4, penalty=0.8 B OPTIONS /billings HTTP/1.1 Host: example3.com ... X-SLA-Control: max-execution-time=2.1, max-execution-cost=0.1, penalty=1.2 C Solution 1: Client asks for details about each service, and make a choice Monday, 13 February 2012
71. Solution 2: User sends control header along the request; services accept or reject the request Client serverA service1 serverB service1 serverC service1 Expect: 100-Continue RESTful SLA negotiation Monday, 13 February 2012
72. Solution 2: User sends control header along the request; services accept or reject the request Client Request POST /billings HTTP/1.1 Content-Type: application/vnd.company.billing+xml X-SLA-Control: max-execution-time=0.8, max-execution-cost=0.4, penalty=1 Expect: 100-Continue <billing>...</billing> Client serverA service1 serverB service1 serverC service1 Expect: 100-Continue RESTful SLA negotiation Monday, 13 February 2012
73. Solution 2: User sends control header along the request; services accept or reject the request Client Request POST /billings HTTP/1.1 Content-Type: application/vnd.company.billing+xml X-SLA-Control: max-execution-time=0.8, max-execution-cost=0.4, penalty=1 Expect: 100-Continue <billing>...</billing> Possible Responses from Services 100 Continue 417 Expectation Failed Client serverA service1 serverB service1 serverC service1 Expect: 100-Continue RESTful SLA negotiation Monday, 13 February 2012
74. Solution 2: User sends control header along the request; services accept or reject the request Client Request POST /billings HTTP/1.1 Content-Type: application/vnd.company.billing+xml X-SLA-Control: max-execution-time=0.8, max-execution-cost=0.4, penalty=1 Expect: 100-Continue <billing>...</billing> Possible Responses from Services 100 Continue 417 Expectation Failed Client serverA service1 serverB service1 serverC service1 Expect: 100-Continue Could be abstracted using intermediary Could be monitored in real-time using intermediary RESTful SLA negotiation Monday, 13 February 2012
75. 4. Conclusion • SOA does not need to be complex • Reuse what works in the real-world • HTTP is a good application protocol. RFC2616 (HTTP/1.1) is a must read • REST requires a paradigm change from RPC Programmers buying into the myth [that “remote access and local access are exactly the same”] may believe that they do not have to change the way they think about programming. A Note on Distributed Computing [Waldo'94] • REST is not a standard, just an architectural style. It could benefit from more research. Monday, 13 February 2012
76. The end Monday, 13 February 2012
77. References • Architectural Styles and the Design of Network-based Software Architectures, Roy T. Fielding http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm • RFC2616 http://www.ietf.org/rfc/rfc2616.txt • REST mailing list http://tech.groups.yahoo.com/group/rest-discuss/ • Implementing REST http://code.google.com/p/implementing-rest • REST in Practice ISBN#978-0-596-80582-1 • RESTful Web Services ISBN#978-0-596-52926-0 • Organization for the Advancement of Structured Information Standards http://www.oasis-open.org/ • Pragmatic SOA Beyond Buzzwords and Flamewars, Stefan Tilkov http://www.infoq.com/presentations/Pragmatic-SOA Monday, 13 February 2012
78. Questions Monday, 13 February 2012