Support services to decide responding asynchronously

[GeraldKrause]

This issue complements the discussion in issue #1961 with a proposal to extend service capabilities for asynchronous processing with callbacks

Status Quo

The current specification supports asynchronous processing only if triggered by the client using preference respond-async (8.2.8.8 Preference respond-async). Moreover, the spec explicitly prohibits services to return status code 202 with a Location header if the request has not included the respond-async preference.

Extended Requirement

There are scenarios, however, where the service may want to decide on its own discretion to return the result asynchronously.

The reason could be at design-time, because the service implements query processing asynchronously, e.g. offload it to a task queue. More advanced implementations could decide at runtime for the given request to deviate from default synchronous processing, e.g. because the server load is currently high, the overall response time is estimated to be large, the logic to create the query result is complex. In such cases, the service would return a 202 with location response header, which is not allowed by the current spec.

Approach

A service that wants to respond to requests asynchronously exposes this behavior as a metadata annotation of a new term in the Capability vocabulary, e.g. Capabilities.AsynchronousRequestsObligatory. The scope could be expressed, i.e. for which type of requests, for which service resources.

Such an annotation would require a client to include the respond-async preference in every request in scope, otherwise the service rejects the request with a 404 status code. For the given request, the service decides if it is processed asynchronously, and returns the result in Preference-Applied accordingly.

[ralfhandl]

No objection to the approach in general.

How to annotate this server behavior needs to be fleshed out.

[ralfhandl]

Possible name for the capability

• AsynchronousRequestsRequired - requests without Prefer: respond-async may be rejected

Services must also specify "Async...Supported" - document by making it the base term.

Should this be on container, on entity set, on operation, ...?

Maybe not a "capability" but a "requirement" or "enforcement"? No, we already have Restrictions in Capabilities.

[GeraldKrause]

Update from discussion on 2024-11-27

We identified these options:

Option A

1. Add the new term AsynchronousRequestsRequired to the Capabilities vocabulary to indicate that the asynchronous preference is required in requests which are otherwise rejected with a 404 status code.
   This term targets the container-level scope, like the existing term AsynchronousRequestsSupported
2. A service that wants to respond asynchronously annotates both terms.
   This option incurs extra efforts for implementations that always try to honor the preference in requests and consequently always apply asynchronous processing.

Option B
Relax the statement in section 11.6 Asynchronous Requests of the protocol spec (second paragraph, second sentence) such that a service may reply to a data service request with 202 Accepted and a Location header also if the request has not included the respond-async preference.

Conclusion
We are in favor of option B. As this would break existing clients, we decided to defer this change to v5.

[mikepizzo]

Because the preferred option would introduce a breaking change, we will move this to V5.