We need a profile for the AAS Repository without the submodel repository "write" superpath methods, so that our API is compliant with the spec and the idea behind the /description interface.
How should it be fixed?
Either a new profile should be created, or perhaps the existing AAS Repository Service Profile should be changed and the submodel repository superpaths should be dropped.
Reasoning
Asset Administration Shell and Submodel "entities" are in a natural many to many relation, so providing write operations as a superpath under a shell resource brings more confusion than value.
For example, given a DELETE shells/{shell_id}/submodels/{submodel_id}, there is no behaviour that is reasonably explainable to the API consumers:
if only the submodel is deleted, and no submodel reference in the shell is deleted, then why is the DELETE submodel operation available on the superpath at all?
if the submodel reference in the shell is deleted, what about the other shells where the same submodel was referenced?
if the submodel reference in all shells in the repository is deleted, then the question arrises why this happened, because an explicit DELETE shells/{shell_id}/submodels/{submodel_id}, with shell_id was called, so why are other shells affected as well?
Example above is only on one of many write operations available. I think in general, write operations on nested RESTful resource which are in many-many relation are not a good idea (IMHO).
The core idea behind the superpath is perfectly reasonable and understandable - it is to provide convenience - best of which is the avoidance of the calling the registry in the case of a monolithic AAS / Submodel repository. I think this is achievable by simply dropping the "write" superpath methods, and keeping the "read" methods.
[x] I have signed the required Developer Certificate of Origin (DCO) already.
DenisBiondic
commented
8 months ago
What is missing?
We need a profile for the AAS Repository without the submodel repository "write" superpath methods, so that our API is compliant with the spec and the idea behind the /description interface.
How should it be fixed?
Either a new profile should be created, or perhaps the existing AAS Repository Service Profile should be changed and the submodel repository superpaths should be dropped.
Reasoning
Asset Administration Shell and Submodel "entities" are in a natural many to many relation, so providing write operations as a superpath under a shell resource brings more confusion than value.
For example, given a
DELETE shells/{shell_id}/submodels/{submodel_id}, there is no behaviour that is reasonably explainable to the API consumers:DELETE shells/{shell_id}/submodels/{submodel_id}, with shell_id was called, so why are other shells affected as well?Example above is only on one of many write operations available. I think in general, write operations on nested RESTful resource which are in many-many relation are not a good idea (IMHO).
The core idea behind the superpath is perfectly reasonable and understandable - it is to provide convenience - best of which is the avoidance of the calling the registry in the case of a monolithic AAS / Submodel repository. I think this is achievable by simply dropping the "write" superpath methods, and keeping the "read" methods.