rest inf 123 – software architecture tdebeauv@uci.edu 1

1

REST

INF 123 – Software architecturetdebeauv@uci.edu

2

Outline

• SOAP and REST• REST constraints and gains• REST guidelines

3

SOAP AND REST

Simple Object Access ProtocolRepresentational State Transfer

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 it’s not working anymore

• It’s about (function) names– Whereas REST is about standard verbs like GET,

POST, etc.

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

6

SOAP message

POST /InStock HTTP/1.1Host: www.example.orgContent-Type: application/soap+xml; charset=utf-8Content-Length: 299SOAPAction: "http://www.w3.org/2003/05/soap-envelope" <?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header></soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.example.org/stock"> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body></soap:Envelope>

7

Metadata vs verbosity

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

Pay attention to the fine print metadata. It’s 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)

• http://oreilly.com/pub/wlg/3005

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

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

12

SOAP vs REST

• SOAP is verbose: large overhead of metadata and boilerplate text

• SOAP

• REST

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserID>12345</pb:UserID> </pb:GetUserDetails> </soap:Body> </soap:Envelope>

GET http://www.acme.com/phonebook/UserDetails/12345

13

Solutions to SOAP’s 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

14

15

16

REST CONSTRAINTSRepresentational State Transfer

17

Reminder: Architectural style

• Set of constraints• Constraints induce properties

– Desirable or undesirable– Design trade-offs

• REST = architectural style of the WWW

18

Resource = information, dataWe 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

20

Deriving REST from other styles

http://roy.gbiv.com/talks/200804_REST_ApacheCon.pdf

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

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

23

Stateful example: SMTPtagus: crista$ telnet smtp.ics.uci.edu 25Trying 128.195.1.219...Connected to smtp.ics.uci.edu.Escape character is '^]'.220 david-tennant-v0.ics.uci.edu ESMTP mailer ready at Mon, 5 Apr 2010 17:15:01 -0700'HELO smtp.ics.uci.edu250 david-tennant-v0.ics.uci.edu Hello barbara-wright.ics.uci.edu [128.195.1.137], pleased to meet youMAIL FROM:<lopes@ics.uci.edu>250 2.1.0 <lopes@ics.uci.edu>... Sender okRCPT TO:<lopes@ics.uci.edu>250 2.1.5 <lopes@ics.uci.edu>... Recipient okDATA354 Enter mail, end with "." on a line by itselftest.250 2.0.0 o360F1Mo029280 Message accepted for deliveryQUIT221 2.0.0 david-tennant-v0.ics.uci.edu closing connectionConnection 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 don’t have any memory management issues

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

26

3 Caching

• Optional• Store data locally so I don’t 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)

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)

28

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

29

Proxy for load balancing: nginx

30

Intermezzo: ISPs

• Internet Service Providers (ISP): COX, Comcast Verizon, UCI

• When a client requests content, it goes through:– The client’s ISP– Intermediary ISP 1– Intermediary ISP 2– The server’s ISP– The server delivers the content

• Many hops = lots of delay

31

tracert/traceroute

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!

33

5 Code on demand

• Optional• Fetch JavaScript when a web page asks for it<html><head><script src=‘blabla.js’></script>• Pros: thinner clients, improves extensibility• Cons: reduces visibility

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)

36

REST Data ElementsUniform Interfaces

(The following slides are from Crista Lopes)

37

Resources and their identifiers

• Resource = Abstraction of information, any information that can be named– A document, a temporal service (“today’s

weather”), collection of other resources– Some are static, some are dynamic

• Identifiers: Universal Resource Identifiers (URIs)

Uniform Interfaces

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

39

HATEOAS

• Hypermedia As The Engine Of Application State• Idea: the application is a state machine

Uniform Interfaces

LoggedOut

CreateAccount

LoggedIn

User

ChangeAccount

LoggedIn

Admin

SearchUsers …

Question is:Where is the clients’ state stored?

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

LoggedOut

LoggedIn

User

ChangeAccount

41

HATEOAS

• Server sends representation of the client’s state back to the client– Hence, REpresentional State Transfer

• Server does not “hold on” to client’s state• Possible next state transitions of the client are

encoded in Hypermedia– Anchors, forms, scripted actions, …

LoggedOut

LoggedIn

User

ChangeAccount

42

MORE REST GUIDELINES

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?

44

Example: Paypal’s API

• https://developer.paypal.com/docs/api/

45

RESTful Design Guidelines

• Embrace hypermedia– Name your resources/features with URIs– Design your namespace carefully

• Hide mechanisms– Bad: http://example.com/cgi-bin/users.pl?name=John– Good: http://example.com/users/John

• Serve POST, GET, PUT, DELETE on those resources– Nearly equivalent to CRUD (Create, Retrieve, Update, Delete)

• Don’t hold on to state– Serve and forget (functional programming-y)

• Consider serving multiple representations– HTML, XML, JSON

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.

https://eee.uci.edu/toolbox/dropbox/index.php?op=createdropboxform

http://us.mc510.mail.yahoo.com/mc/welcome?.gx=1&.tm=1271634041& .rand=9anflcttvlh7n#_pg=showFolder&fid=Inbox&order=down&tt=237&pSize=100& .rand=952814729&.jsrand=4316826

47

Choosing money CGI over power REST is a mistake almost everyone makes.

They just don’t know …

48

RESTful Design Guidelines

Canonicalexample

49

REST vs Linked Data

• Linked data – A data model– Proposed by Berners-Lee

• REST – An interaction model– Proposed by Fielding

50

Taylor’s 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)

51

For you to read/watch

• http://www.infoq.com/articles/rest-introduction

• http://rest.elkstein.org/• https://

groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

• https://www.youtube.com/watch?v=e2PyeXRwhCE

• https://www.cloudflare.com/overview