1. INF 123 – Software architecture tdebeauv@uci.edu
REST
INF 123 – Software architecture

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

3. SOAP and REST Simple Object Access Protocol
Representational State Transfer
SOAP and REST

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.1 Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 299
SOAPAction: "
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="
<soap:Header></soap:Header>
<soap:Body>
<m:GetStockPrice xmlns:m="
<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)

10. REST and SOAP They happened concurrently
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 Internet 1992: WWW = Internet + 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=" soap:encodingStyle="
<soap:body pb="
<pb:GetUserDetails>
<pb:UserID>12345</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>
GET

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

16. Representational State Transfer
REST constraints

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, data
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

20. Deriving REST from other styles
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: SMTP
tagus: crista$ telnet smtp.ics.uci.edu 25
Trying
Connected to smtp.ics.uci.edu.
Escape character is '^]'.
220 david-tennant-v0.ics.uci.edu ESMTP mailer ready at Mon, 5 Apr :15: '
HELO smtp.ics.uci.edu
250 david-tennant-v0.ics.uci.edu Hello barbara-wright.ics.uci.edu [ ], pleased to meet you
MAIL
Sender ok
RCPT
Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
test .
o360F1Mo Message accepted for delivery
QUIT
david-tennant-v0.ics.uci.edu 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 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
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 Elements Uniform Interfaces
(The following slides are from Crista Lopes)

37. Resources and their identifiers
Uniform Interfaces
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)

38. Uniform Interfaces
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

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

40. HATEOAS Non-REST 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
Logged In
User
Change
Account

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
Logged In
User
Change
Account

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

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)
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.
.rand=9anflcttvlh7n#_pg=showFolder&fid=Inbox&order=down&tt=237&pSize=100&
.rand= &.jsrand=

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

48. RESTful Design Guidelines
Canonical
example

49. REST vs Linked Data Linked data REST 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