1 / 30

Client

Request. Client. Server. 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"?>

Download Presentation

Client

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Request Client Server Response

  2. 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> Request Server Client 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/" 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> Synchrones POST Response

  3. 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> Request Server Client HTTP/1.1 4xx OR 5xx Error Code Some Headers Some optional payload Synchrones POST Error case Response

  4. 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 <?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> Request Server Client Asynchrones POST HTTP/1.1 202 Accepted Retry-After: 100 Location: http://services.odata.org/monitor/12345 Response

  5. GET /monitor/12345 Host: services.odata.org Request Server Client Requestisstill in processing mode. Resultis not ready. Client shouldasklater for the resultagain. HTTP/1.1 202 Accepted Retry-After: 100 Location: http://services.odata.org/monitor/12345 Response

  6. GET /monitor/12345 Host: services.odata.org Request Server Client Processingisfinished. Response to the original requestisserved in a minimalisticenvelop (message/http) 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

  7. GET /monitor/12345 Host: services.odata.org Request Server Client Processingisfinished. Response to the original requestisserved in a minimalisticenvelop (message/http) 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

  8. GET /monitor/12345 Host: services.odata.org Request Server Client Server Error Messages 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

  9. GET /monitor/12345 Host: services.odata.org Request Server Client Server Error Message 410 Gone • HTTP/1.1 410 Gone: The requested resource is no longer available at the server. This condition is expected to be considered permanent. Reasons: Asynchronesprocessing 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

  10. 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 asyncbehavior?

  11. 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?

  12. 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.

  13. 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 state it MUST send a 405 “Method not allowed” • (Should we DELETE the async response ressource? … a bit weird) • (Should we DELETE a asyncTaskressource?)

  14. “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

  15. 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

  16. (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.

  17. (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.

  18. (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 = 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.

  19. (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.

  20. (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 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.

  21. 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

  22. ResponseID ResponseID

  23. DELETE /monitor/12345 HTTP/1.1 Request Server Client HTTP/1.1 200 OK OR HTTP/1.1 204 No Content Synchrones DELETE Response

  24. DELETE /monitor/12345 HTTP/1.1 Request Server Client HTTP/1.1 4xx OR 5xx Error Code Some Headers Some optional payload Synchrones DELETE Error case Response

  25. DELETE /monitor/12345 HTTP/1.1 Prefer: respond-async, wait=5 Request Server Client Asynchrones DELETE HTTP/1.1 202 Accepted Retry-After: 100 Location: http://services.odata.org/monitor/4711 Response

  26. GET /monitor/4711 Host: services.odata.org Request Server Client Requestisstill in processing mode. Resultis not ready. Client shouldasklater for the resultagain. HTTP/1.1 202 Accepted Retry-After: 100 Location: http://services.odata.org/monitor/4711 Response

  27. GET /monitor/4711 Host: services.odata.org Request Server Client Processingisfinished. Response to the original requestisserved in a minimalisticenvelop (message/http) HTTP/1.1 200 OK Content-Type: message/http HTTP/1.1 200 OK OR HTTP/1.1 204 No Content Asynch. Response Response

  28. GET /monitor/4711 Host: services.odata.org Request Server Client Processingisfinished. Response to the original requestisserved in a minimalisticenvelop (message/http) 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

  29. GET /monitor/4711 Host: services.odata.org Request Server Client Server Error Messages 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

  30. GET /monitor/4711 Host: services.odata.org Request Server Client Server Error Message 410 Gone • HTTP/1.1 410 Gone: The requested resource is no longer available at the server. This condition is expected to be considered permanent. Reasons: Asynchronesprocessing 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

More Related