Activity
Sebastian Iancu May 31, 2021 at 10:59 AM
Yes, indeed: PUT /ehr/{ehr_id}/composition/{versioned_object_uid}
will either create or update, depending on If-Match
header and existence of supplied URL-id (versioned_object_uid
).
So the general idea is that the API should honor the request of persisting a resource in relation with an explicit id, and off course, under the hood if the resource is versioned (like Composition), then certain conditions has to be met (like those related to If-Match).
How does it sounds?
(disclaimer: this is just an investigation about choices and design requirements, it does not mean that we’ll directly change this)
see Put Composition
Jake Smolka May 28, 2021 at 12:09 PM
To answer the question on how EHRbase deals with it:
We are currently ignoring the IDs from the request body and generate IDs on the server-side.
Apart from that I don’t really understand the PUT idea. There’s a PUT for the same path already. Or are you proposing to “overload” it, so it either create the new resource with the given ID OR updates it, if the ID exists already and the If-Match
header matches?
Matija Polajnar May 17, 2021 at 6:19 AM
I vote for adding the PUT variant with UID in the URL (and non-mandatorily in the payload as well, but if that one is different from the one in the URL, that is a 400 Bad Request).
As for POST probably the cleanest solution would be to return 400 Bad Request if UID was present in the payload, but that would probably break compatibility for some existing implementations, so simply accepting and respecting the UID in the payload, if present, sound reasonable as well.
For https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition-composition-post, in the example payload, the composition's UID is specified.
This behaviour needs to be documented.
"If it's not existing it should be generated.
If it's present and unique it should be kept."
Another suggestion is to specify behaviour for PUT with {versioned_object_uid}
See discussion on Slack:
Matija Polajnar May 13th at 10:10 AM
Another question about https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition-composition-post: in the example payload, composition's UID is specified. Is that intentional, and what should the CDR do in this case: actually use that UID (if available), or generate a fresh one nevertheless? And if there is no UID in the composition, it should implicitly be auto-generated, right?
8 replies
Bjørn Næss 2 days ago
If it's not existing it should be generated.
If it's present and unique it should be kept.
For many clients the UID might be needed for computional reasons. Thus it might be needed to generate UID on the client (= user of API).
Matija Polajnar 2 days ago
I see your point; we had to implement "placeholders" like $composition0, $composition1, $compositionSelf, ... to enable cross-linking of compositions within a contribution to circumvent the fact we don't support client-side generated UIDs for compositions (except on administrative API). Can @sebastian.iancu please document that in the next ITS release then?
Sebastian Iancu 2 days ago
I’ll check first the reason we have it this way ( right now i’m not behind my pc); i rember we discussed about this, but don’t recall the conclusion. We also support this feature so personally i’m fine with that and slso agree should be documented -jira
Sebastian Iancu 18 minutes ago
I checked, and it looks like we added this in 2017 (v1.0.0) - So I assume is not a mistake or an accident.
Sebastian Iancu 16 minutes ago
As said above, we (Code24) also support this flow the Bjorn described it - I'm curious how is it at EHRBase, @birger or @Jake?
Sebastian Iancu 8 minutes ago
If we would like to be more restful, we should in fact support the PUT action with a {versioned_object_uid} (so a client-side generated UID) and leave POST with empty UID, so that it gets generated by the server-side.
Sebastian Iancu 3 minutes ago
I would fancy more this way of handling client-side requirements on UIDs. If the server is not supporting it, it is very easy for the server to indicate it. Also, it will bring more consistency in relation with GET.
Sebastian Iancu 2 minutes ago
And we could make this change in R1.1 with a deprecate note for client-generated UIDs on POST