Behaviour for use of composition uid's in POST requests needs clarification

serefarikan commented 6 years ago

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.

bostjanl commented 5 years ago

This is a question for spec not just the REST api.

sebastian-iancu commented 5 years ago

This relates to https://openehr.atlassian.net/browse/SPECPR-322

sebastian-iancu commented 5 years ago

on a duplicate issue, Thomas replied:

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. https://github.com/openEHR/specifications-ITS-REST/issues/71#issuecomment-416964944

openEHR / specifications-ITS-REST

Behaviour for use of composition uid's in POST requests needs clarification #70