Presentation is loading. Please wait.

Presentation is loading. Please wait.

REST INF 123 – Software architecture 1.

Similar presentations

Presentation on theme: "REST INF 123 – Software architecture 1."— Presentation transcript:

1 REST INF 123 – Software architecture 1

2 Outline SOAP and REST REST constraints and gains REST guidelines 2

3 SOAP AND REST Simple Object Access Protocol Representational State Transfer 3

4 From RPC to SOAP: RPC Pass remote procedure name and arguments Expect a return value Procedure signature is implicit – If you change the signature, people have no way to know why its not working anymore Its about (function) names – Whereas REST is about standard verbs like GET, POST, etc. 4

5 From RPC to SOAP: SOAP 1998: Simple Object Access Protocol 2000: Web Service Description Language (WSDL) uses SOAP as underlying protocol, cf SOA slides SOAP = XML RPC done right Long/verbose structured XML messages – Verbosity != metadata 5

6 SOAP message 6 POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "" IBM

7 Metadata vs verbosity 7 There are two kinds of pain. The sort of pain that makes you strong, or useless pain that is only suffering.

8 Metadata vs verbosity 8 Pay attention to the fine print metadata. Its far more important than the selling price data itself.

9 Amazon uses both REST and SOAP Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface (2003) 9

10 REST and SOAP They happened concurrently – SOAP: 1998 – REST: 2000 SOAP = envelope, REST = postcard SOAP derived from RPC REST is not a move against SOAP REST is very complex – But it looks simpler than SOAP 10

11 REST History Hypertext – 1945 memex (Vannevar Bush) – 1967 hypertext (Project Xanadu) Internet – 1969 ARPANET (army) 1992: WWW = Internet + hypertext 2000: REST = reverse-engineer/document the WWW architectural style HTTP is not mandatory for REST, but it helps 11

12 SOAP vs REST SOAP is verbose: large overhead of metadata and boilerplate text SOAP REST 12 12345 GET

13 Solutions to SOAPs verbosity MTOM: Message Transmission Optimization Mechanism – Encode/compress XML into binary XOP: XML-binary Optimized Packaging – To encode/decode MTOM TLDR: Binary-encoded XML over HTTP But HTTP = hypertext transfer protocol 13

14 14

15 15

16 REST CONSTRAINTS Representational State Transfer 16

17 Reminder: Architectural style Set of constraints Constraints induce properties – Desirable or undesirable – Design trade-offs REST = architectural style of the WWW 17

18 Resource = information, data 18 We have great resources at our disposal.

19 REST is made of several styles Client-Server Stateless Cache Layered Code on demand Uniform Interface These styles are not always inter-compatible But they are in the case of the WWW 19

20 Deriving REST from other styles 20 No style

21 1 Client-server Cf week 2 Separation of concerns: client display vs server logic – Display is client-side: clients can have different UIs Each website has a server Same client (browser) can access multiple servers 21

22 2 Stateless interactions AKA context-free interactions Stateless interaction does not mean no data in the server The server does not store any client-specific information between two requests State is client-side or in a database 22

23 Stateful example: SMTP 23 tagus: crista$ telnet 25 Trying Connected to Escape character is '^]'. 220 ESMTP mailer ready at Mon, 5 Apr 2010 17:15:01 -0700' HELO 250 Hello [], pleased to meet you MAIL FROM: 250 2.1.0... Sender ok RCPT TO: 250 2.1.5... Recipient ok DATA 354 Enter mail, end with "." on a line by itself test. 250 2.0.0 o360F1Mo029280 Message accepted for delivery QUIT 221 2.0.0 closing connection Connection closed by foreign host.

24 Gains from statelessness Immune to server restart/migration – Server restart = lose all data – But stateless = no data to lose! No server affinity – Client requests can be processed by ANY server, not just one particular server Scalability – Server never knows if/when client sends its next request – So stateful servers timeout the sessions of clients with long inter-request times – Stateless servers dont have any memory management issues 24

25 Losses from statelessness Client is less efficient Server needs to pull data for every request – Pulling data is straightforward when this data is a static web page (most of the WWW in the 90s) How do you authenticate users? – Cookies (not good?) – External auth and directory services 25

26 3 Caching Optional Store data locally so I dont have to retrieve it In clients, in servers, or in intermediaries (cf layered constraint) Reduces latency Improves efficiency and scalability But degrades reliability (stale data) 26

27 4 Layered Intermediaries between client and server – Proxies, such as nginx – Caches – Content Delivery Network, such as Akamai – Web accelerator, such as CloudFlare Pros: ability to balance load (improves scalability), can reduce latency (when cache hits) Cons: can add latency (when cache misses) 27

28 28 Do you know what I like about people intermediaries? They stack so neatly.

29 Proxy for load balancing: nginx 29

30 Intermezzo: ISPs Internet Service Providers (ISP): COX, Comcast Verizon, UCI When a client requests content, it goes through: – The clients ISP – Intermediary ISP 1 – Intermediary ISP 2 – The servers ISP – The server delivers the content Many hops = lots of delay 30

31 tracert/traceroute 31

32 Content Delivery Network: Akamai Akamai pays ISPs to host their servers within a few hops of many clients – Many clients = urban areas I pay Akamai to deliver my content Now, when a client requests my content: – Client ISP – Akamai server delivers my content! 32

33 5 Code on demand Optional Fetch JavaScript when a web page asks for it Pros: thinner clients, improves extensibility Cons: reduces visibility 33

34 34 I won't be a slave to anybody or anything you can order with a toll free number any static code.

35 6 Uniform interface The hardest constraint to get right Uniform identification of resources Manipulation of resources via representations Hypermedia as the engine of app state (HATEOAS) 35

36 REST Data Elements Uniform Interfaces (The following slides are from Crista Lopes) 36

37 Resources and their identifiers Resource = Abstraction of information, any information that can be named – A document, a temporal service (todays weather), collection of other resources – Some are static, some are dynamic Identifiers: Universal Resource Identifiers (URIs) Uniform Interfaces 37

38 Representations Server returns representations of resources, not the resources themselves. – E.g. HTML, XML Server response contains all metadata for client to interpret the representation Uniform Interfaces 38

39 HATEOAS Hypermedia As The Engine Of Application State Idea: the application is a state machine Uniform Interfaces Logged Out Create Account Create Account Logged In User Logged In User Change Account Change Account Logged In Admin Logged In Admin Search Users Search Users … Question is: Where is the clients state stored? 39

40 HATEOAS Non-REST – Clients state kept on the server – Server is both state machine and holder of state REST – State machine on the server – At any step, client is sent a complete picture of where it can go next, ie its state and transitions Logged Out Logged In User Logged In User Change Account Change Account 40

41 HATEOAS Server sends representation of the clients state back to the client – Hence, REpresentional State Transfer Server does not hold on to clients state Possible next state transitions of the client are encoded in Hypermedia – Anchors, forms, scripted actions, … Logged Out Logged In User Logged In User Change Account Change Account 41


43 HTTP Operations GET PUT DELETE HEAD OPTIONS TRACE POST CONNECT Idempotent methods: the side effects of many invocations are exactly the same as the side effects of one invocation PS: remember main and subroutines? 43

44 Example: Paypals API 44

45 RESTful Design Guidelines Embrace hypermedia – Name your resources/features with URIs – Design your namespace carefully Hide mechanisms – Bad: – Good: Serve POST, GET, PUT, DELETE on those resources – Nearly equivalent to CRUD (Create, Retrieve, Update, Delete) Dont hold on to state – Serve and forget (functional programming-y) Consider serving multiple representations – HTML, XML, JSON 45

46 RESTful Design Guidelines URIs are nouns The 8 HTTP operations are verbs Very different from CGI-inspired web programming: Many/most web frameworks promote URIs as verbs and query data as nouns – old CGI model. 46

47 47 Choosing money CGI over power REST is a mistake almost everyone makes. They just dont know …

48 RESTful Design Guidelines Canonical example 48

49 REST vs Linked Data Linked data – A data model – Proposed by Berners-Lee REST – An interaction model – Proposed by Fielding 49

50 Taylors REST principles Any information is a resource, named by an URL. (uniform interface) Resource representation is accompanied by metadata about the representation. (uniform interface, code on demand) Interactions are context-free. (stateless) Small set of methods. Each method can be applied to any resource. The result of a method is a representation. Idempotent operations help caching. (cache) Intermediaries use metadata from requests or responses to filter, redirect, or modify representations. This is transparent to client and server. (layered, cache) 50

51 For you to read/watch introduction introduction discuss/conversations/topics/5841 discuss/conversations/topics/5841 whCE whCE 51

Download ppt "REST INF 123 – Software architecture 1."

Similar presentations

Ads by Google