Conflicting definitions for query parameter assetIds for call GET /lookup/shells #504
Description
There is an inconsistency regarding the serialization of query parameter assetIds for GET /lookup/shells.
As a running example, let's assume we want to search for two specific asset id assetId1=foo and assetId2=bar.
In OpenAPI it is defined as array<string> with the following description
A list of specific Asset identifiers. Each Asset identifier is a base64-url-encoded SpecificAssetId
This sound very much like each search parameter is first serialized as JSON, encoded to base64, and then the two base64 encodings are concatenated with ,, i.e. the result call would be
GET /lookup/shells?assetIds=eyJuYW1lIjogImFzc2V0SWQxIiwidmFsdWUiOiAiZm9vIn0=,eyJuYW1lIjogImFzc2V0SWQyIiwidmFsdWUiOiAiYmFyIn0=
In the AAS specification however there is this section
This encoding (serialize to JSON + base64url) is also used for SpecificAssetIds, i.e. for GetAllAssetAdministrationShellIdsByAssetLink (/lookup/shells). For the example "[{"name": "globalAssetId","value": "http://example.company/myAsset"},{"name": "myOwnInternalAssetId","value": "12345ABC"}]", the resulting base64url-encoded value of the query parameter is
"?assetIds=W3sibmFtZSI6ICJnbG9iYWxBc3NldElkIiwidmFsdWUiOiAiaHR0cDovL2V4YW1wbGUuY29tcGFueS9teUFzc2V0In0seyJuYW1lIjogIm15T3duSW50ZXJuYWxBc3NldElkIiwidmFsdWUiOiAiMTIzNDVBQkMifV0".
If several key-value-pairs are included, all must be part of the key-value-pairs on the server.
According to this, the correct behavior would be to first create JSON array containing two JSON objects and then serialize and base64 encode this resulting in GET /lookup/shells?assetIds=W3sibmFtZSI6ICJhc3NldElkMSIsInZhbHVlIjogImZvbyJ9LHsibmFtZSI6ICJhc3NldElkMiIsInZhbHVlIjogImJhciJ9XQ==
Both definitions are conflicting and this conflict needs to be resolved.
To my it seems like the definition in the specification is the correct one as it is so concrete that there is no room for interpretations. Also it seems more natural to serialize a single JSON object instead of having a list of comma-separated strings that each are base64-encoded JSON serializations.
- I have signed the required Developer Certificate of Origin (DCO) already.