Part 2 should also offer async resources

[sebastiankb]

What?

Currently, the API is defined in a way that the requests are synchronised. E.g., a GET /shells/{id} results directly to a AAS response (if exists). In practice, however, this will most likely not be possible since creating an AAS will take some time. An async API is needed.

How?

Introduce async resources such as /shellsAsync/{id} that returns a status message (e.g., pending, running, completed or failed) with a status resource. A sample usage can be found here: https://w3c.github.io/wot-profile/#async-action-response

[sebbader-sap]

Thanks for raising the topic. Async and batch requests are currently on the roadmap for a minor release after V3.0.
Let's use this issue to track our progress.

[aorzelskiGH]

Examples for long running requests are:

• An AAS is generated while the API request is retrieved
• A submodel is retrieved from an existing backend server, e.g. a document from an existing document server

[BirgitBoss]

Decision 2024-03-05 TF AAS API
Bulk-operations as introduced in V3.1 for registry are asyncronous and can be used for this purpose. Bulk operations for repositories are planned for V3.x

compare to #148: is it the same request or what is the difference?