You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* add proposal for an async aasx profile
* correct result of the get .../results/... endpoint
* add missing appearances of the async aasx file server operations
title: DotAAS Part 2 | HTTP/REST | AASX File Server Service Specification
4
+
description: >-
5
+
The async profile of the File Server Service Specification as part of the [Specification of the Asset Administration Shell: Part 2](http://industrialdigitaltwin.org/en/content-hub).
6
+
7
+
Publisher: Industrial Digital Twin Association (IDTA) 2026
Copy file name to clipboardExpand all lines: documentation/IDTA-01002-3/modules/ROOT/pages/changelog.adoc
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,7 @@ Note: Changes in Metamodel (IDTA-01001) will not be listed here, although they h
14
14
15
15
Major Changes:
16
16
17
+
* Add the asynchronous AASX File Server Service Specification (https://github.com/admin-shell-io/aas-specs-api/issues/347[#347])
17
18
* Changing the serialization format for AASX packages from "application/asset-administration-shell-package+xml" to "application/aas+zip" in the OpenAPI files for the Asset Administration Shell Repository Service Specification and the Submodel Repository Service Specification. This change is necessary to align with the actual content type used by implementations and to avoid confusion, as the previous content type was not registered and could be misinterpreted as an XML-based format. (https://github.com/admin-shell-io/aas-specs-api/issues/538[#538])
18
19
19
20
@@ -25,14 +26,16 @@ Minor Changes:
25
26
* Editorial: Remove links to SwaggerHub from the HTTP API section, as the links are maintained in the service specifications and profiles sections. (https://github.com/admin-shell-io/aas-specs-api/issues/475[#475])
26
27
* Editorial fixes in Table 2 of the Query Language specification (https://github.com/admin-shell-io/aas-specs-api/issues/507[#507])
| GenerateSerializationByIds|change a| Added a note to clarify the intended behavior for transitively referenced concept descriptions. (https://github.com/admin-shell-io/aas-specs-api/issues/510[#510])
35
35
| PutAssetAdministrationShellById|change a| Added the missing `id` input parameter and a note explaining the behavior in case the AAS identifier does not match the value of `id`. (https://github.com/admin-shell-io/aas-specs-api/issues/506[#506])
36
+
| PostAsyncAASXPackage|new a| New API Operation for the asynchronous AASX File Server Service Specification (https://github.com/admin-shell-io/aas-specs-api/issues/347[#347])
37
+
| GetAasxAsyncStatus|new a| New API Operation for the asynchronous AASX File Server Service Specification (https://github.com/admin-shell-io/aas-specs-api/issues/347[#347])
38
+
| GetAasxAsyncResult|new a| New API Operation for the asynchronous AASX File Server Service Specification (https://github.com/admin-shell-io/aas-specs-api/issues/347[#347])
The client sends a POST request to the "/packages-async" endpoint with the AASX file in the request body.
704
+
The server immediately responds with an Accepted (status code: 202) message containing the link to an endpoint where the client can fetch status information about his request (see <<aasx-upload-invocation>>).
705
+
This status endpoint is located at "/packages-async/\{handleId}".
706
+
In case the request is incorrect and the server already recognizes it, the server responds directly with the according status code, e.g. 400. If the server can only recognize the error during later processing and not at the time it receives the request, it responds with an Accepted (202) message at first. Hence, a received Accepted message does not guarantee the client that its request is valid in every case.
707
+
If the server has not finished processing the request, the status endpoint responds with a message with the attribute "executionState" set to "Running".
708
+
As soon as the processing is finished, the status endpoints deliver a Found (HTTP status code 302) response with the location of the result in the Location response header.
709
+
The result is provided at the "/packages-async/result/\{handleId}" endpoint.
710
+
In case incorrect inputs have been provided by the client but the server was only able to recognize this during processing, or if the server perceived any other error during processing, the server must still provide the result object with status code 200 and set the attribute "executionState" to "Failed".
711
+
712
+
713
+
714
+
690
715
== Bulk Operations
691
716
692
717
This chapter provides a description of the Bulk APIs.
|<<aasx-file-server-service-specification-SSP-001, AasxFileServerServiceSpecification/SSP-001>>The full feature set of the AASX File Server Service Specification
323
+
|<<aasx-file-server-service-specification-SSP-002, AasxFileServerServiceSpecification/SSP-002>>The async feature set of the AASX File Server Service Specification
0 commit comments