Client
Server
Request
Response
Request
<?xml version="1.0" encoding="utf-8"?>
<Entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<title type="text"></title> …
<content type="application/xml"> …
</content>
</Entry>
Server
Client
POST /OData/OData.svc/Categories HTTP/1.1
Host: services.odata.org
Accept: application/atom+xml
Content-type: application/atom+xml Content-Length: 634
HTTP/1.1 201 CREATED
Created Content-Length: 1072 Date: Sat, 27 Feb 2010 21:39:54 GMT
Synchrones POST
Location: http://services.odata.org/OData/OData.svc/Categories(10)
Content-Type: application/atom+xml;charset=utf-8
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Entry xml:base="http://services.odata.org/OData/OData.svc/"
xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<id>http://services.odata.org/OData/OData.svc/Categories(10)</id>
<title type="text"></title> …
<category term="DataServiceProviderDemo.Category"
scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<content type="application/xml"> …
</content>
Response
</Entry>
Request
<?xml version="1.0" encoding="utf-8"?>
<Entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<title type="text"></title> …
<content type="application/xml"> …
</content>
</Entry>
Server
Client
POST /OData/OData.svc/Categories HTTP/1.1
Host: services.odata.org
Accept: application/atom+xml
Content-type: application/atom+xml Content-Length: 634
Synchrones POST
Error case
HTTP/1.1 4xx OR 5xx Error Code
Some Headers
Some optional payload
Response
Request
<?xml version="1.0" encoding="utf-8"?>
<Entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<title type="text"></title> …
<content type="application/xml"> …
</content>
</Entry>
HTTP/1.1 202 Accepted
Retry-After: 100
Location: http://services.odata.org/monitor/12345
Response
Server
Client
POST /OData/OData.svc/Categories HTTP/1.1
Host: services.odata.org
Accept: application/atom+xml
Content-type: application/atom+xml Content-Length: 634
Prefer: respond-async, wait=5
GET /monitor/12345
Host: services.odata.org
Server
Client
Request
HTTP/1.1 202 Accepted
Retry-After: 100
Location:
http://services.odata.org/monitor/12345
Response
GET /monitor/12345
Host: services.odata.org
Server
Client
Request
HTTP/1.1 200 OK
Content-Type: message/http
HTTP/1.1 201 CREATED
Created Content-Length: 1072 Date: Sat, 27 Feb 2010 21:39:54 GMT
Location: http://services.odata.org/OData/OData.svc/Categories(10)
Content-Type: application/atom+xml;charset=utf-8
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Entry xml:base=http://services.odata.org/OData/OData.svc/….>
<id>http://services.odata.org/OData/OData.svc/Categories(10)</id>
<title type="text"></title> …
<category term="DataServiceProviderDemo.Category"
scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<content type="application/xml"> …
</content>
</Entry>
Asynch. Response
Response
GET /monitor/12345
Host: services.odata.org
Server
Client
Request
HTTP/1.1 200 OK
Content-Type: message/http
HTTP/1.1 4xx OR 5xx Error Code
Some Headers
Some optional payload
Asynch. Response
Response
GET /monitor/12345
Host: services.odata.org
Server
Client
Request
HTTP/1.1 401 Unauthorized
OR
HTTP/1.1 403 Forbidden
OR
HTTP/1.1 404 Not Found
OR
HTTP/1.1 5xx Server Error
Response
GET /monitor/12345
Host: services.odata.org
Server
Client
Request
HTTP/1.1 410 Gone:
The requested resource is no longer available at the server. This condition is
expected to be considered permanent.
Reasons: Asynchrones processing was killed by
• a system administrator
• a system process
• the client via “DELETE /monitor/12345 HTTP/1.1”
• The client waited too long
Remark: The server can also answer with a unspecific 404 in these cases
Response
Questions / Decision points
• Async:
Core Feature or Extension Feature?
For Client, for Server?
Must a client be prepared for an async response even
he hasn’t ask for it?
 Do we need a prefer header?
Capabilities Vocabulary needed to announce which
elements offer async behavior?
Questions / Decision points
• Do we need a optional asyncTask resource for clients
interested in the internal server processing state?
• If yes, should we
• define the structure of this resource or
• only a vocabulary or
• nothing?
Questions / Decision points
DELETE
• Delete during Async processing:
– If the server offers to delete the processing of an
async request, it must be able to “rollback”
everything he has done so far.
 After a successful deletion the server must be
in the same state as before the async request
processing was started.
Questions / Decision points
DELETE
If the server offers a delete operation, what is the right resource
to send the DELETE request to?
– James S: Client should send the DELETE to the monitor resource as
announced by the location header in the last 202 accepted response
– If the server doesn’t offer DELETE
• in general
• for the current async processing (in general or based on the
processing state
it MUST send a 405 “Method not allowed”
– (Should we DELETE the async response ressource? … a bit weird)
– (Should we DELETE a asyncTask ressource?)
“Monitor” resource
..is a multipurpose resource
202  processing is still ongoing.
Location and retry-after header used.
Additional information could be send in
payload (format)
200  processing finished; result is in payload.
Content type is message/http
DELETE 
monitor acts as a representation of
the
task processing the async request on the
server
Prefer Header for HTTPdraft-snell-http-prefer-18 (1/2013)
An example request specifying the
"respond-async" preference:
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async
{Data}
An example asynchronous response
using "202 Accepted":
While the "202 Accepted" response
status is defined by [I-D.ietf-httpbis-p2semantics], little guidance is given on
how and when to use the response code
and the process for determining the
subsequent final result of the operation
is left entirely undefined. Therefore,
whether and how any given server
supports asynchronous responses is an
implementation specific detail that is
considered to be out of the scope of this
specification.
HTTP/1.1 202 Accepted
Location: http://example.org/collection/123
James Snell agreed, that the example is misleading :
 location header should point to a monitor resource
(HTTP/1.1): Semantics and Content draft-ietf-httpbis (10/2012)
• 7.3.3. 202 Accepted
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be
acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an
asynchronous operation such as this. The 202 response is intentionally
non-committal. Its purpose is to allow a server to accept a request for
some other process (perhaps a batch-oriented process that is only run
once per day) without requiring that the user agent's connection to
the server persist until the process is completed.
The representation returned with this response SHOULD include an
indication of the request's current status and either a pointer to a
status monitor or some estimate of when the user can expect the
request to be fulfilled.
(HTTP/1.1): Message Syntax and draft-ietf-httpbis-p1-messaging-21
(10/2012)
7.3.1. Internet Media Type message/http
The message/http type can be used to enclose a single
HTTP request or response message, provided that it
obeys the MIME restrictions for all "message" types
regarding line length and encodings.
(HTTP/1.1): Semantics and Content draft-ietf-httpbis-p2-semantics-21
8.1.2. Location
The "Location" header field MAY be sent in responses to refer to a specific
resource in accordance with the semantics of the status code. Location = URIreference For 201 (Created) responses, the Location is the URI of the new
resource which was created by the request. For 3xx (Redirection) responses,
the location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. The field value consists of a single URI-reference.
When it has the form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI ([RFC3986],
Section 5). If the original URI, as navigated to by the user agent, did contain a
fragment identifier, and the final value does not, then the original URI's
fragment identifier is added to the final value.
(HTTP/1.1): Semantics and Content draft-ietf-httpbis-p2-semantics-21
For example, the original URI "http://www.example.org/~tim", combined
with a field value given as:
Location: /pub/WWW/People.html#tim would result in a final value of
"http://www.example.org/pub/WWW/People.html#tim" An original URI
"http://www.example.org/index.html#larry", combined with a field value
given as: Location: http://www.example.net/index.html would result in a final
value of "http://www.example.net/index.html#larry", preserving the original
fragment identifier. Note: Some recipients attempt to recover from Location
fields that are not valid URI references. This specification does not mandate
or define such processing, but does allow it. There are circumstances in which
a fragment identifier in a Location URI would not be appropriate. For
instance, when it appears in a 201 (Created) response, where the Location
header field specifies the URI for the entire created resource. Note: The
Content-Location header field (Section 3.1.4.2) differs from Location in that
the Content-Location identifies the most specific resource corresponding to
the enclosed representation. It is therefore possible for a response to contain
header fields for both Location and Content-Location.
(HTTP/1.1): Semantics and Content draft-ietf-httpbis-p2-semantics-21
8.1.3. Retry-After
The header "Retry-After" field can be used with a 503 (Service Unavailable)
response to indicate how long the service is expected to be unavailable to the
requesting client. This field MAY also be used with any 3xx (Redirection)
response to indicate the minimum time the user-agent is asked to wait before
issuing the redirected request. The value of this field can be either an HTTPdate or an integer number of seconds (in decimal) after the time of the
response.
Retry-After = HTTP-date / delta-seconds
Time spans are non-negative decimal integers, representing time in seconds.
delta-seconds = 1*DIGIT
Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
Thoughts
• Async should be beneficial to respond to Delta
requests
• Rework for spec:
– $batch currently returns 202 with a synchronous
response. For streaming a response we should use
transfer-encoding = chunked
ResponseID
ResponseID
Server
Client
Request
DELETE /monitor/12345 HTTP/1.1
Synchrones DELETE
HTTP/1.1 200 OK
OR
HTTP/1.1 204 No Content
Response
Server
Client
Request
DELETE /monitor/12345 HTTP/1.1
Synchrones DELETE
HTTP/1.1 4xx OR 5xx Error Code
Some Headers
Error case
Some optional payload
Response
Server
Client
Request
DELETE /monitor/12345 HTTP/1.1
Prefer: respond-async, wait=5
HTTP/1.1 202 Accepted
Retry-After: 100
Location:
http://services.odata.org/monitor/4711
Response
GET /monitor/4711
Host: services.odata.org
Server
Client
Request
HTTP/1.1 202 Accepted
Retry-After: 100
Location:
http://services.odata.org/monitor/4711
Response
GET /monitor/4711
Host: services.odata.org
Server
Client
Request
HTTP/1.1 200 OK
Content-Type: message/http
HTTP/1.1 200 OK
OR
HTTP/1.1 204 No Content
Asynch. Response
Response
GET /monitor/4711
Host: services.odata.org
Server
Client
Request
HTTP/1.1 200 OK
Content-Type: message/http
HTTP/1.1 4xx OR 5xx Error Code
Some Headers
Some optional payload
Asynch. Response
Response
GET /monitor/4711
Host: services.odata.org
Server
Client
Request
HTTP/1.1 401 Unauthorized
OR
HTTP/1.1 403 Forbidden
OR
HTTP/1.1 404 Not Found
OR
HTTP/1.1 5xx Server Error
Response
GET /monitor/4711
Host: services.odata.org
Server
Client
Request
HTTP/1.1 410 Gone:
The requested resource is no longer available at the server. This condition is
expected to be considered permanent.
Reasons: Asynchrones processing was killed by
• a system administrator
• a system process
• the client via “DELETE /monitor/4711 HTTP/1.1”
• The client waited too long
Remark: The server can also answer with a unspecific 404 in these cases
Response