Take a REST - Speaker Deck

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Agenda 1. Distributed applications 2. Styles for Service Oriented Architectures A. WS-* B. REST 3. Quality of service 4. Conclusion Monday, 13 February 2012

Slide 3

Slide 3 text

1. Distributed Applications Monday, 13 February 2012

Slide 4

Slide 4 text

Objectives Integration across application boundaries Monday, 13 February 2012

Slide 5

Slide 5 text

Objectives Integration across organizational boundaries Monday, 13 February 2012

Slide 6

Slide 6 text

Evolution APPLICATION 1 APPLICATION 2 APPLICATION 3 GUI LOGIC DATA Monolithic applications • duplication • maintenance cost • no data sharing Monday, 13 February 2012

Slide 7

Slide 7 text

Evolution Applications sharing data • duplication • fragile Monday, 13 February 2012

Slide 8

Slide 8 text

Evolution Applications sharing objects over the network • looks great! Monday, 13 February 2012

Slide 9

Slide 9 text

Evolution Applications sharing objects over the network • tight coupling • complex • vendor lock-in Monday, 13 February 2012

Slide 10

Slide 10 text

Evolution Service Oriented Architectures • loose-coupling • language independence • reusability • composability Monday, 13 February 2012

Slide 11

Slide 11 text

Great Monday, 13 February 2012

Slide 12

Slide 12 text

2. Styles e-potpourri.com Monday, 13 February 2012

Slide 13

Slide 13 text

• WS-* (SOAP/WSDL) • REST (HTTP) Styles for Service Oriented Architectures http://www.oasis-open.org/ http://www.ics.uci.edu/~ﬁelding/pubs/dissertation/rest_arch_style.htm Monday, 13 February 2012

Slide 14

Slide 14 text

WS-* Monday, 13 February 2012

Slide 15

Slide 15 text

WS-* Monday, 13 February 2012

Slide 16

Slide 16 text

WS-* Monday, 13 February 2012

Slide 17

Slide 17 text

WS-* • Pros • Apparent simplicity • Kind-of standardized, somewhat good interoperability Monday, 13 February 2012

Slide 18

Slide 18 text

• 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

Slide 19

Slide 19 text

WS-* Monday, 13 February 2012

Slide 20

Slide 20 text

WS-* Protocol independence is a failure, everything is tunneled over HTTP Monday, 13 February 2012

Slide 21

Slide 21 text

WS-* Protocol independence is a failure, everything is tunneled over HTTP SOAP Envelope SOAP Header SOAP Body Monday, 13 February 2012

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Well... Monday, 13 February 2012

Slide 26

Slide 26 text

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-speciﬁc 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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

HTTP Monday, 13 February 2012

Slide 29

Slide 29 text

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 ... Monday, 13 February 2012

Slide 30

Slide 30 text

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 ... Request Monday, 13 February 2012

Slide 31

Slide 31 text

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 ... Request Response Monday, 13 February 2012

Slide 32

Slide 32 text

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 ... method Request Response Monday, 13 February 2012

Slide 33

Slide 33 text

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 ... method URI Request Response Monday, 13 February 2012

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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 ... 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

Slide 39

Slide 39 text

The REST Uniform Interface Identiﬁcation of resources Resource manipulation through representations Hypermedia as the engine of application state Self-descriptive messages Monday, 13 February 2012

Slide 40

Slide 40 text

The REST Uniform Interface Identiﬁcation 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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

The REST Uniform Interface Identiﬁcation 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 ... ... Request Response Request Response Monday, 13 February 2012

Slide 43

Slide 43 text

The REST Uniform Interface Identiﬁcation 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 ... ... GET /events/1234 Host: example.com Accept: text/calendar ... BEGIN:VCALENDAR ... END:VCALENDAR Request Response Request Response Monday, 13 February 2012

Slide 44

Slide 44 text

The REST Uniform Interface Identiﬁcation 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 ... ... 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

Slide 45

Slide 45 text

The REST Uniform Interface Identiﬁcation 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 Take a REST! 2010-10-04T12:00:00Z Transition between services Monday, 13 February 2012

Slide 46

Slide 46 text

The REST Uniform Interface Identiﬁcation 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 Take a REST! 2010-10-04T12:00:00Z Transition between services Monday, 13 February 2012

Slide 47

Slide 47 text

The REST Uniform Interface Identiﬁcation 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 ﬁnal (objective) state. Client must know a priori about the media-types of the services. Monday, 13 February 2012

Slide 48

Slide 48 text

The REST Uniform Interface Identiﬁcation 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 ... method URI headers Request Response status headers body Monday, 13 February 2012

Slide 49

Slide 49 text

The REST Uniform Interface Identiﬁcation 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 ... method URI headers Request Response status headers body Client Server Monday, 13 February 2012

Slide 50

Slide 50 text

The REST Uniform Interface Identiﬁcation 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 ... method URI headers Request Response status headers body Client Server proxy Monday, 13 February 2012

Slide 51

Slide 51 text

The REST Uniform Interface Identiﬁcation 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 ... method URI headers Request Response status headers body Client Server cache proxy Monday, 13 February 2012

Slide 52

Slide 52 text

The REST Uniform Interface Identiﬁcation 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 ... method URI headers Request Response status headers body Client Server cache load-balancer proxy Monday, 13 February 2012

Slide 53

Slide 53 text

Claim RESTful HTTP moves you closer to SOA goals than WS-* Stefan Tilkov Monday, 13 February 2012

Slide 54

Slide 54 text

• Addressability Each resource is uniquely identiﬁed. • 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

Slide 55

Slide 55 text

OK, but what about... Monday, 13 February 2012

Slide 56

Slide 56 text

3. Quality of Service Monday, 13 February 2012

Slide 57

Slide 57 text

Claim Advanced WS-* standards are overrated Stefan Tilkov Monday, 13 February 2012

Slide 58

Slide 58 text

Security • WS-*: WS-Security • REST: HTTP + SSL/TLS is sufﬁcient in 99% of cases. Message-based security is way too expensive. Monday, 13 February 2012

Slide 59

Slide 59 text

Scalability • REST: constraint of statelessness means that requests are not bound to a speciﬁc server. Per-URI (service) policies can be applied. Load- Balancer Client serverA/service1 serverB/service1 serverC/service1 Monday, 13 February 2012

Slide 60

Slide 60 text

• 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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Management / Auditing WS-*: Web Services for Distributed Management (WSDM) ? REST: intermediaries have plenty of logs about your services, and load-balancers can regularly check speciﬁc 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

Slide 63

Slide 63 text

Service discovery • WS-*: UDDI (centralized) • REST: link relationships (distributed) Monday, 13 February 2012

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Service Level Agreement? • WS-*: WS-Agreement • REST: intelligent use of HTTP Monday, 13 February 2012

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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 ... Client serverA service1 serverB service1 serverC service1 Expect: 100-Continue RESTful SLA negotiation Monday, 13 February 2012

Slide 73

Slide 73 text

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 ... 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

Slide 74

Slide 74 text

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 ... 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

Slide 75

Slide 75 text

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 beneﬁt from more research. Monday, 13 February 2012

Slide 76

Slide 76 text

The end Monday, 13 February 2012

Slide 77

Slide 77 text

References • Architectural Styles and the Design of Network-based Software Architectures, Roy T. Fielding http://www.ics.uci.edu/~ﬁelding/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

Slide 78

Slide 78 text

Questions Monday, 13 February 2012