Even though @wolandscat has pointed out that use of OBJECT_VERSION_IDs for COMPOSITION.uid values does not imply any versioning semantics as per the specifications, at least one vendor and probably more (according to slack comments) use meaningful uid values for COMPOSITIONs.
The discussion on slack did not produce an answer to the following question: "do we consider this non-standard, yet widely(?) applied practice for rest specifications".
If the answer to the above question is yes, then we need to clarify what the REST endpoint should do when
- a system id that is different than the REST endpoint's is provided as in xyz::some_other_system::1
- a version that is not equal to 1 as in xyz::rest_implementing_system::3
Because in case of meaningful COMPOSION.uid s the above conditions imply imports rather than creating new compositions.
if the answer to the above question is no, there are still decisions to be made.
If the REST back end simply ignores the whole (OBJECT_VERSION_ID) uid or components of it, does this constitute a problem REST wise, since we're creating a resource that is different than the one provided (uid dropped)? If we're determining the identifier of the resource (via setting its uid), should not this be a PUT? RESTful design assumes POST will create the resource identifier as far as I remember
Also, @bjornna made a point regarding client side generation of UIDs which is required to commit a folder and compositions together where the folder has uids of compositions referenced. I am not sure if this is possible with the current REST api, but assuming this will be introduced later, this requirement conflicts with the behaviour in which server silently drops incoming uid values.
I tried to come up with a set of rules that satisfy all conditions above and failed, even when we assume uid has no versioning semantics. Suggestions are welcome.
Even though @wolandscat has pointed out that use of OBJECT_VERSION_IDs for COMPOSITION.uid values does not imply any versioning semantics as per the specifications, at least one vendor and probably more (according to slack comments) use meaningful uid values for COMPOSITIONs.
The discussion on slack did not produce an answer to the following question: "do we consider this non-standard, yet widely(?) applied practice for rest specifications".
If the answer to the above question is yes, then we need to clarify what the REST endpoint should do when
Because in case of meaningful COMPOSION.uid s the above conditions imply imports rather than creating new compositions.
if the answer to the above question is no, there are still decisions to be made.
If the REST back end simply ignores the whole (OBJECT_VERSION_ID) uid or components of it, does this constitute a problem REST wise, since we're creating a resource that is different than the one provided (uid dropped)? If we're determining the identifier of the resource (via setting its uid), should not this be a PUT? RESTful design assumes POST will create the resource identifier as far as I remember
Also, @bjornna made a point regarding client side generation of UIDs which is required to commit a folder and compositions together where the folder has uids of compositions referenced. I am not sure if this is possible with the current REST api, but assuming this will be introduced later, this requirement conflicts with the behaviour in which server silently drops incoming uid values.
I tried to come up with a set of rules that satisfy all conditions above and failed, even when we assume uid has no versioning semantics. Suggestions are welcome.