1. Handling Asynchronous REST Operations
임형준
충남대학교 컴퓨터공학과
데이터베이스시스템연구실
2019년 2월 24일 일요일

2. Table of Contents REST(REpresentation State Transfer)
State Transition
Caching
Asynchronous REST Operations(Paper)
REST vs SOAP
Example REST Requests
RESTful Web service

3. REST REpresentation State Transfer
Create applications based on well designed URLs
Take advantage of web caching
Migrate toward Resource-Oriented Computing (ROC)
Resource
Client
Boeing747.html
Fuel requirements
Maintenance schedule
...
The Client references a Web resource using a URL. A representation
of the resource is returned (in this case as an HTML document).
The representation (e.g., Boeing747.html) places the client application in
a state. The result of the client traversing a hyperlink in Boeing747.html
is another resource is accessed. The new representation places the client
application into yet another state. Thus, the client application changes (transfers)
state with each resource representation --> Representation State Transfer!

4. Example: Airline Reservation Service
Suppose that an airline wants to create a telephone reservation(Web based reservation) system for customers to call in and make flight reservations
The airline wants to ensure that its premier members get immediate service, its frequent flyer members get expedited service and all others get regular service
There are two main approaches to implementing the reservation service
Approach 1: One-Stop Shopping
Approach 2: X are Cheap!

5. Approach 1: One-Stop Shopping
Premier Members
Frequent Flyer Members
Regular Members
Airline Reservations
Answering
Machine
Premier
Customer
Representative
F.F.
Regular
Premier Members
Frequent Flyer Members
Regular Members
Web
Reservation
Service
Determine
Priority
Premier
Customer
F.F.
Regular
client
Approach 1 Disadvantages
There is currently no industry accepted practice (rules) for expressing priorities, so rules would need to be made. The clients must learn the rule, and the Web service application must be written to understand the rule.
This approach is based upon the incorrect assumption that a URL is "expensive" and that their use must be rationed.
The Web service is a central point of failure. It is a bottleneck. Load balancing is a challenge.
It violates Tim Berners-Lee Web Design, Axiom 0 (see next slide).

6. Web Design, Axiom 0 Tim Berners-Lee, director of W3C
Axiom 0: all resources on the Web must be uniquely identified with a URI
resource1
URL1
resource2
URL2
resource3
URL3

7. Approach 2: X are Cheap! Different Telephone Number Different URLs
Premier Members
Frequent Flyer Members
Regular Members
1-800-Premier
Premier
Customer
Representative
F.F.
Regular
1-800-Frequent
1-800-Reservation
Different
Telephone
Number
Premier
Member
Reservation
Service
Different
URLs
client
Premier Members
Frequent
Flyer
Reservation
Service
Approach 2 Advantages
The different URLs are discoverable by search engines and UDDI registries.
It's easy to understand what each service does simply by examining the URL, i.e., it exploits the Principle of Least Surprise.
There is no need to introduce rules. Priorities are elevated to the level of a URL. "What you see is what you get."
It's easy to implement high priority - simply assign a fast machine at the premier member URL.
There is no bottleneck. There is no central point of failure.
Consistent with Axiom 0.
client
Frequent Flyer Members
Regular
Member
Reservation
Service
client
Regular Members

8. REST in One Slide Resources Names Representations Verbs (URI, XRI, …)
[Resources have Names]
Names
Verbs
Representations
Resources
(CRUD, …)
(HTML, XML, …)
(URI, XRI, …)
[Everything is a Resources]
Customers
Locations
Items
[Resources have REPRESENTATIONS]
HTML: text/html, application/xhtml+xml, …
XML: text/xml, application/atom+xml, …
Binary: image/png, application/pdf, …
[Resources support simple VERBS]
Create, Read, Update, Delete
POST, GET, PUT, DELETE

9. REST Concept XML JSON XML JSON Resources Res 1 URL VERB Res 2 GET
HTTP Request
HTTP Response
Status
URL
VERB
GET
POST
PUT
DELETE
Payload
XML
JSON
Payload
XML
JSON

10. The REST way of Implementing the Web Services
Response
(HTML/XML doc)
Web Server
HTTP GET request
URL 1
HTTP response
URL 2
HTTP POST
URL 3
URL to submitted PO PO
(HTML/XML)
Parts
List
Part

11. Data Returned - Parts List
<?xml version="1.0"?>
<p:Parts xmlns:p="
xmlns:xlink="
xmlns:xsi="
xsi:schemaLocation=
"
<Part id="00345" xlink:href="
<Part id="00346" xlink:href="
<Part id="00347" xlink:href="
<Part id="00348" xlink:href="
</p:Parts>
Note that the parts list has links to get detailed info about each part.
This is a key feature of REST. The client transfers from one state to
the next by examining and choosing from among the alternative URLs
in the response document.

12. State Transitions
Let us consider a client application as a state machine - each resource representation that it receives causes it to transition to the next state S0 S1
Receive Resource 1
Representation S2
Receive Resource 2
...
State Transition Diagram for a Client Application

13. State Transitions in a REST-based Network
Receive Resource 1
Representation
S2a
S2b
S2c 2a 2b 2c
Receive Resource 2a 3a 3b
S3a
S3b
Receive Resource 3b 4a 4b 4c
Each resource representation contains
hyperlinks. Following a hyperlink takes
the client to the next state. Thus, within
the resource representations themselves
are pointers to the next states
Each resource representation contains
hyperlinks. Following a hyperlink takes
the client to the next state. Thus, within
the resource representations themselves
are pointers to the next states

14. Caching
In a network-based application it is ofterntimes the communications which are the bottleneck
Web
Server
Resource 1
Cache
“I have a copy in my
cache. Here it is.” 2a 2b 2c
The cache shortens the distance that
the client must go to get the data, thus
speeding up the request.

15. REST and Caching (cont.)
The results of a resource request contains an indication in the HTTP header of whether these results are cacheable (and when the data will become stale)
If the HTTP header says that it is cacheable, then cache servers can make a local copy
Later, if a client requests the same resource then the client can return a cached copy
Cache
Server
Desired resource
Method = GET
Forward request
Return cached copy

16. Handling Asynchronous REST Operations

17. Handling Asynchronous REST Operations
In a RESTful context, how do you handle state-changing operations (POST, PUT, DELETE) which have substantial and unpredictable latency?
Resource-based approach
Comet style implementation
Web hooks

18. Resource-based Approach
A new "Status" resource model..., with the following fields:
"uri" - URI upon which the client may perform GET operations to poll for completion. Each accepted asynchronous operation will receive a unique status URI, so that multiple operations may be initiated and tracked at once
"status" - Integer code describing the completion status (0=success, nonzero=error code), returned only when "progress" returns 100
"message" - Message suitable for reporting completion status to a human user, returned only when "progress" returns 100
"progress" - Integer percent completed indicator, which MUST return 100 only when the operation has been completed (either successfully or unsuccessfully)
This resource object can be used as follows:
For any and all PUT/POST/DELETE operations, we return "202 In progress" and a "Status" resource, ... designed to give a hook that implementers can make cheap to poll

19. Resource-based Approach
GET
polling … 1
uri1 2
uri2 3
uri3 4
uri4
100
uri100
uri0
progress …
uri
0(success) or nonzero(error code)
status
Message suitable for reporting completion status
message

20. Comet Style Implementation
Keeping the HTTP channel open for the duration of a long running request
Initial response MUST have HTTP status 202 ("Accepted"),... and entity body containing the initial Status resource for this operation. In the status resource, the "uri" and "progress" fields MUST be populated, and the "progress" field MUST contain a value of 0 indicating that the operation is beginning
The URI value returned in the initial response MUST respond to GET requests by returning an updated version of the Status resource. Typically, the "progress" field will be increased towards 100, but MUST NOT be set to 100 until the operation completes
When the operation has completed (either successfully or unsuccessfully), a "final" representation of the Status resource MUST be returned, with a "progress" field set to 100, and a "status" field set to 0 (for successful completion) or a non-zero value for unsuccessful completion

21. Comet Style Implementation
0(beginning)
100(final)
uri
uri100
202(Accept)
0 or nonzero
서비스
서비스
이용자
HTTP Channel
progress
uri
status

22. Web hooks
Using two independent "one-way" invocations - one to start a long-running operation and the other one to notify a requester that it is completed
The inbound representation of the operation request MAY contain a "webhook" field, whose value is a URI where the client expects a callback. If this field is not present, no webhook callback will be performed
When the operation has completed (either successfully or unsuccessfully), the server will perform a POST request to the webhook URI, with... an entity body containing the final Status resource for this operation
Client can match a completion report back to the original request by comparing the "uri" field value to the one returned in the initial Status response, or by providing unique webhook URIs for each asynchronous request

23. REST vs SOAP

24. The REST way of Implementing the Web Services
Response
(HTML/XML doc)
Web Server
HTTP GET request
URL 1
HTTP response
URL 2
HTTP POST
URL 3
URL to submitted PO PO
(HTML/XML)
Parts
List
Part

25. Data Returned - Parts List
<?xml version="1.0"?>
<p:Parts xmlns:p="
xmlns:xlink="
xmlns:xsi="
xsi:schemaLocation=
"
<Part id="00345" xlink:href="
<Part id="00346" xlink:href="
<Part id="00347" xlink:href="
<Part id="00348" xlink:href="
</p:Parts>
Note that the parts list has links to get detailed info about each part.
This is a key feature of REST. The client transfers from one state to
the next by examining and choosing from among the alternative URLs
in the response document.

26. Implementing the Web Services using SOAP
Request
(XML doc)
Response
Web Server
SOAP envelope
HTTP POST
URL 1
HTTP Response
getPartsList()
getPart(id)
SOAP Server PO
submit(PO)
Note the use of the same URL (URL 1) for all transactions. The SOAP Server parses the
SOAP message to determine which method to invoke. All SOAP messages are sent
using an HTTP POST.

27. Note about the SOAP URI SOAP Server
It is not a SOAP requirement all messages be funneled to the same URL:
URL 1
SOAP
Server
HTTP POST
getPartsList()
getPart(id)
submit(PO)
However, it is common among SOAP vendors to follow this practice.
For example, here is the URL for all requests when using Apache SOAP:
[host]/soap/servlet/messagerouter

28. Implementing the Web Service using SOAP
Service: Get a list of parts
The client creates a SOAP document that specifies the procedure desired
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="
<soap:Body>
<p:getPartsList xmlns:p="
</soap:Body>
</soap:Envelope>
Then the client will HTTP POST this document to the SOAP server at:
The SOAP server takes a quick peek into this document to determine
what procedure to invoke.

29. Data Returned - Parts List
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="
<soap:Body>
<p:getPartsListResponse xmlns:p="
<Parts>
<Part-ID>00345<Part-ID>
<Part-ID>00346<Part-ID>
<Part-ID>00347<Part-ID>
<Part-ID>00348<Part-ID>
</Parts>
<p:getPartsListResponse>
</soap:Body>
</soap:Envelope>
Note the absence of links. Why is this? A URL that points to a SOAP
service is meaningless since the URL to a SOAP service is just to the
SOAP server. Thus, the URL would need to be supplemented with
some indication of which method to invoke at that URL.
[Note: of course this response could contain a URL to a REST-ful service.]

30. State Transitions in a SOAP-based Network
Receive SOAP
from Application 1
S2a
S2b
S2c
from Application 2a
S3a
S3b
from Application 3b
In a pure SOAP system each SOAP message
will be just data, no hyperlinks. Consequently,
the decision on which resource to access next
must be made out-of-band.

31. Why don't SOAP Documents Contain Hyperlinks?
In a pure SOAP system, that is where all accesses are to SOAP-based Web services, then each SOAP document will be an island
The reason for this is simple: with SOAP a URL is meaningless by itself. The URL just points to a SOAP server. To be useful the URL must be accompanied by the SOAP message

32. Processing the Request/Response Payload
With both REST and SOAP you need prior agreement on the semantics of the data
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="
<soap:Body>
<p:getPartsListResponse xmlns:p="
<Parts>
<Part-ID>00345<Part-ID>
<Part-ID>00346<Part-ID>
<Part-ID>00347<Part-ID>
<Part-ID>00348<Part-ID>
</Parts>
<p:getPartsListResponse>
</soap:Body>
</soap:Envelope>
<?xml version="1.0"?>
<p:Parts xmlns:p="
xmlns:xlink="
xmlns:xsi="
xsi:schemaLocation=
"
<Part id="00345" xlink:href="
<Part id="00346" xlink:href="
<Part id="00347" xlink:href="
<Part id="00348" xlink:href="
</p:Parts>
Note: if the payload is in the format of RDF or DAML then the client application may be able to dynamically learn the meaning of the response data.
As we saw earlier, with REST there are links to the next state built within each response. We hinted earlier at how a client application may be able to reason dynamically about which link to traverse. Thus, dynamic learning of response data combined with dynamic reasoning of link traversals would yield a self-reasoning automata. This is the next step of the Web!
With both REST and SOAP client applications
will need to understand these responses.

33. Conclusion REpresentational State Transfer In a nutshell;
Server-side resources identified by a URI
Access is over HTTP, verb tied to action
GET to read the value of a resource
POST to create a new resource
PUT to update an existing resource
DELETE to delete a resource
Returned data is “plain” – XML or JSON
Asynchronous REST Operations
Resource-based approach
Comet style implementation
Web hooks

34. References
Handling Asynchronous REST Operations, InfoQ, Boris Lublinsky,
Slow REST, ongoing,
5-Minute Introduction to REST, Roger L. Costello, Timothy D. Kehoe, xFront
Introduction to REST, Steve Bjorg, mindtouch, May, 2007
REST(Representational State Transfer), Roger L. Costello, XML Technology Course
Example REST Requests, Amazon Product Advertising API,
A RESTful Web service, an example, Paul James,