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.