Client

Clie

nt

Serv

er

Request

Response

POST /OData/OData.svc/Categories HTTP/1.1 Host: services.odata.org Accept: application/atom+xml Content-type: application/atom+xml Content-Length: 634

<?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 201 CREATED Created Content-Length: 1072 Date: Sat, 27 Feb 2010 21:39:54 GMTLocation: 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> </Entry>

Clie

nt

Serv

er

Request

Response

http://services.odata.org/OData/OData.svc/Categories(10)

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 4xx OR 5xx Error CodeSome Headers

Some optional payload

Clie

nt

Serv

er

Request

Response

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


HTTP/1.1 202 AcceptedRetry-After: 100Location: http://services.odata.org/monitor/12345

Clie

nt

Serv

er

Request

Response

Asynchrones POST

GET /monitor/12345Host: services.odata.org


Clie

nt

Serv

er

Request

Response

Request is still in processing mode.Result is not ready. Client should ask later for the result again.


HTTP/1.1 200 OKContent-Type: message/http

Clie

nt

Serv

er

Request

Response

HTTP/1.1 201 CREATED Created Content-Length: 1072 Date: Sat, 27 Feb 2010 21:39:54 GMTLocation: 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

Processing is finished.

Response to the original

request is served in a

minimalistic envelop

(message/http)

http://services.odata.org/OData/OData.svc/Categories(10)

http://services.odata.org/OData/OData.svc/



Clie

nt

Serv

er

Request

Response



Asynch. Response





(message/http)


HTTP/1.1 401 UnauthorizedOR

HTTP/1.1 403 ForbiddenOR

HTTP/1.1 404 Not FoundOR

HTTP/1.1 5xx Server Error

Clie

nt

Serv

er

Request

Response

Server Error Messages


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

Clie

nt

Serv

er

Request

Response

Server Error Message410 Gone

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 pointsDELETE

• 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 pointsDELETE

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 stateit MUST send a 405 “Method not allowed”

– (Should we DELETE the async response ressource? … a bit weird)– (Should we DELETE a asyncTask ressource?)

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-7.5.5

“Monitor” resource

..is a multipurpose resource202 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/httpDELETE 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":

HTTP/1.1 202 Accepted Location: http://example.org/collection/123

While the "202 Accepted" response status is defined by [I-D.ietf-httpbis-p2-semantics], 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.

James Snell agreed, that the example is misleading : location header should point to a monitor resource

http://tools.ietf.org/html/draft-snell-http-prefer-18#section-2.1

(HTTP/1.1): Semantics and Content draft-ietf-httpbis (10/2012)

• 7.3.3. 202 AcceptedThe 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/httpThe 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. LocationThe "Location" header field MAY be sent in responses to refer to a specific resource in accordance with the semantics of the status code. Location = URI-reference 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.


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.


8.1.3. Retry-AfterThe 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 HTTP-date 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

ResponseIDResponseID

DELETE /monitor/12345 HTTP/1.1

HTTP/1.1 200 OKOR

HTTP/1.1 204 No Content

Clie

nt

Serv

er

Request

Response

DELETE /monitor/12345 HTTP/1.1



Clie

nt

Serv

er

Request

Response

DELETE /monitor/12345 HTTP/1.1Prefer: respond-async, wait=5


Clie

nt

Serv

er

Request

Response

Asynchrones DELETE



Clie

nt

Serv

er

Request

Response

Request is still in processing mode.Result is not ready. Client should ask later for the result again.



Clie

nt

Serv

er

Request

Response

HTTP/1.1 200 OKOR

HTTP/1.1 204 No Content

Asynch. Response





(message/http)



Clie

nt

Serv

er

Request

Response



Asynch. Response





(message/http)


HTTP/1.1 401 UnauthorizedOR

HTTP/1.1 403 ForbiddenOR

HTTP/1.1 404 Not FoundOR

HTTP/1.1 5xx Server Error

Clie

nt

Serv

er

Request

Response

Server Error Messages


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

Clie

nt

Serv

er

Request

Response

Server Error Message410 Gone

Client

Documents

Transcript of Client