[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 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>
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:
There are two scenarios in which links are being returned which are then later used to retrieve information, following a previous request, from the server. These are:
• The service has provided a Location header pointing to a status monitor resource, in a response to a request which specified the respond-async preference in the prefer header.
• The service has provided a delta-link in a response to a request in which the client expressed his desire to be able to track subsequent changes, by specifying the odata.track-changes preference in the prefer header.
To prevent having to poll the server for updates, not knowing if any information is available, the client MAY specify the odata.callback preference requesting the service to notify the consumer when data has become available.
The odata.callback preference MUST specify a URL to a service endpoint, using a parameter named 'url', that the service will invoke to notify the consumer. If the URL specifies an HTTP endpoint, the service will execute a HTTP GET request against the specified URL to notify the consumer. A service may support other, non HTTP, service endpoint protocols. A service SHOULD advertise the supported callback protocols using the capability annotation "CallbackProtocols".
The odata.callback preference only has meaning when used in combination with the respond-async and odata.track-changes preferences.
If the service honors the odata.callback preference it MUST include odata.callback in the Preference-Applied response header.
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>
Resolution: Updated the proposal after further discussion.
> 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]