[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (ODATA-289) Callback for notification after async invocation of Create, Update, Delete and Service Operations
[ http://tools.oasis-open.org/issues/browse/ODATA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hubert Heijkers updated ODATA-289:
----------------------------------
Proposal:
Introduce a new prefer header named 'odata.callback' which can be used in combination with either the respond-async or odata.track-changes preferences. The following is the text proposed to be added to the protocol document:
To prevent having to poll the server for updates, not knowing if request has finished in the async case or changes have become available in the delta-link case, the client MAY specify the odata.callback preference requesting the service to notify the consumer when the respective event has occurred.
The odata.callback preference can be used only in following two situations:
• when requesting asynchronous processing of a request i.c.w. the respond-async preference
• on a synchronous GET request to a delta-link
If the service honors the odata.callback preference it MUST include odata.callback in the Preference-Applied response header.
For the asynchronous request case the odata.callback preference, when applied, will result in the service invoking the specified service endpoint once the service has finished processing the request.
In the case of a GET request to a delta-link at a time where there are no changes available, the preference, when applied, results in a 202 Accepted response to the GET request with a location header specifying the delta-link to be used to check for future updates. The service will invoke the specified service endpoint once new changes become available. If changes are available the odata.callback preference MUST NOT be applied.
The odata.callback preference MUST specify a URL, using a parameter named 'url', to a service endpoint which the service needs to invoke to notify the consumer. A service supporting callback SHOULD at least support the HTTP protocol. If the URL specifies references an HTTP endpoint, the service executes a HTTP GET request against the specified URL to notify the consumer. If a service support additional, non HTTP, protocols it SHOULD advertise the supported protocols using the capability annotation "CallbackProtocols".
Capability Annotation:
<Term Name="CallbackProtocols" Type="Collection(Capabilities.CallbackProtocolType)" AppliesTo="EntityContainer EntitySet">
<Annotation Term="Core.Description" String="Lists all types of supported callback endpoints for this container or entity set" />
</Term>
<ComplexType Name="CallbackProtocolType">
<Property Name="Id" Type="Edm.String">
<Annotation Term="Core.Description" String="Protocol Identifier" />
</Property>
<Property Name="UrlTemplate" Type="Edm.String">
<Annotation Term="Core.Description" String="URL Template including parameters. Parameters are enclosed in curly braces {}
as defined in RFC6570" />
</Property>
<Property Name="DocumentationUrl" Type="Edm.String" Nullable="true">
<Annotation Term="Core.Description" String="Human readable description of the meaning of the URL Template parameters" />
<Annotation Term="Core.IsURL"></Annotation>
</Property>
</ComplexType>
was:
Introduce a new prefer header named 'odata.callback' which can be used in combination with either the respond-async or odata.track-changes preferences. The following is the text proposed to be added to the protocol document:
To prevent having to poll the server for updates, not knowing if request has finished in the async case or changes have become available in the delta-link case, the client MAY specify the odata.callback preference requesting the service to notify the consumer when the respective event has occurred.
The odata.callback preference can be used in two situations:
• when requesting asynchronous processing of a request i.c.w. the respond-async preference
• on a synchronous GET request to a delta-link
If the service honors the odata.callback preference it MUST include odata.callback in the Preference-Applied response header.
For the asynchronous request case the odata.callback preference, when applied, will result in the service invoking the specified service endpoint once the service has finished processing the request.
In the case of a GET request to a delta-link at a time where there are no changes available, the preference, when applied, results in a 202 Accepted response to the GET request with a location header specifying the delta-link to be used to check for future updates. The service will invoke the specified service endpoint once new changes become available. If changes are available the odata.callback preference MUST NOT be applied.
The odata.callback preference MUST specify a URL, using a parameter named 'url', to a service endpoint which the service needs to invoke to notify the consumer. A service supporting callback SHOULD at least support the HTTP protocol. If the URL specifies references an HTTP endpoint, the service executes a HTTP GET request against the specified URL to notify the consumer. If a service support additional, non HTTP, protocols it SHOULD advertise the supported protocols using the capability annotation "CallbackProtocols".
Capability Annotation:
<Term Name="CallbackProtocols" Type="Collection(Capabilities.CallbackProtocolType)" AppliesTo="EntityContainer EntitySet">
<Annotation Term="Core.Description" String="Lists all types of supported callback endpoints for this container or entity set" />
</Term>
<ComplexType Name="CallbackProtocolType">
<Property Name="Id" Type="Edm.String">
<Annotation Term="Core.Description" String="Protocol Identifier" />
</Property>
<Property Name="UrlTemplate" Type="Edm.String">
<Annotation Term="Core.Description" String="URL Template including parameters. Parameters are enclosed in curly braces {}
as defined in RFC6570" />
</Property>
<Property Name="DocumentationUrl" Type="Edm.String" Nullable="true">
<Annotation Term="Core.Description" String="Human readable description of the meaning of the URL Template parameters" />
<Annotation Term="Core.IsURL"></Annotation>
</Property>
</ComplexType>
> Callback for notification after async invocation of Create, Update, Delete and Service Operations
> -------------------------------------------------------------------------------------------------
>
> Key: ODATA-289
> URL: http://tools.oasis-open.org/issues/browse/ODATA-289
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: OData URL Conventions
> Affects Versions: V4.0_WD01
> Environment: [Proposed]
> Reporter: Ramanjaneyulu Malisetti
> Fix For: V4.0_CSD02
>
>
> URL convention for Create and Update implicitly assumes that clients make synchronous invocation. However, some data sources may take longer time to fulfill the request and hence suggest clients to make asynchronous invocation of these operations and response will be available at specific URL.
> Similar mechanism for service operations as well
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]