[OASIS Issue Tracker] (ODATA-809) Define non-message format for final response of async request

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Zurmuehl updated ODATA-809:
----------------------------------

    Proposal: 
Define a new json representation for an asynchronous response which is the response of the initial data service request, if successful. In this case the response headers are the headers that would have been returned had the response returned successfully. In the case that the asynchronously executing operation resulted in an error, define an error code and recommended message for "The asynchronous request resulted in an error." with an inner-error containing the status code and error text of the asynchronous operation.

For backward compatibility, clients that specify an Accept Header of "application/http" would still get back the message format, but clients that don't specify an Accept Header that allows "application/http" but do specify "application/json" (with or without format parameters) for non-batch requests would get this JSON response instead of the response wrapped as an HTTP-Message. For async. batch request the client could specify an Accept Header "multipart/mixed" when requesting the monitor resource to get back the response unwrapped.

  was:
Define a new json representation for an asynchronous response which is the response of the initial data service request, if successful. In this case the response headers are the headers that would have been returned had the response returned successfully. In the case that the asynchronously executing operation resulted in an error, define an error code and recommended message for "The asynchronous request resulted in an error." with an inner-error containing the status code and error text of the asynchronous operation.

For backward compatibility, clients that specify a Accept Header of "application/http" would still get back the message format, but clients that don't specify a Accept Header that allows "application/http" but do specify "application/json" (with or without format parameters) for non-batch requests would get this JSON response instead of the response wrapped as an HTTP-Message. For async. batch request the client could specify an Accept Header "multipart/mixed" when requesting the monitor resource to get back the response unwrapped.


> Define non-message format for final response of async request
> -------------------------------------------------------------
>
>                 Key: ODATA-809
>                 URL: https://issues.oasis-open.org/browse/ODATA-809
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA02
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>              Labels: AdoptionBlocker
>             Fix For: V4.1_WD01
>
>
> Today we define that, once an async result completes, polling the previously returned location header returns an HTTP-Message response that wraps the response (status, headers and body) that would have been returned if the request had processed synchronously:
> "A GET request to the status monitor resource returns 200 OK once the asynchronous processing has completed. This response MUST include a Content-Type header with value application/http and a Content-Transfer-Encoding header with value binary as described in [HTTP-Message]. The response body MUST enclose a single HTTP response which is the response to the initial Data Service Request."
> We did this in order to distinguish between the case that the request for status returned an error and the case where the response to the initial asynchronously request was an error.
> Everyone understands this once explained to them, but nobody likes it.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)