wolandscat
commented
6 years ago My view (and actually, the documentation's view) is that COMPOSITION.uid should just be a simple Guid, if it is populated. There are questions about whether, if it is not populated on the client side, whether the server should add a Guid, and also what should be in that field on a retrieve.
sebastian-iancu
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
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.