Stream: implementers
Topic: logical ids and uploads
Brian Reinhold (Nov 20 2016 at 14:51):
After the FHIR dev days I would like to get confirmation on the behavior and use of logical ids in uploads. This is what I expect:
For individual resource uploads (a resource not in a Bundle)
1. In a PUT update operation the client specifies the logical id.
a. If the resource does not exist, the resource is created with the logical id specified by the client. The server responds with a 201.
b. If the resource exists, and the contents of the resource are the same as what is present on the server, the resource contents does not change though the server-maintained meta-data for that resource does. The server responds with a 200.
c. If the resource exists, and the contents of the resource are different than what is present on the server, the resource contents MAY be selectively updated at the discretion of the server. The client needs to GET the resource if it wants to validate that all changes were made. The server responds with a 200.
2. In a PUT conditional update operation the client does NOT need to specify the id
a. If the resource does not exist, the resource is created and the server specifies the logical id. The server responds with a 201.
b. If only ONE resource satisfying the conditional upload criterium is found, and the contents of the resource are the same as what is present on the server, the resource contents does not change though the server-maintained meta-data for that resource does. The server responds with a 200.
c. If only ONE resource satisfying the conditional upload criterium is found, and the contents of the resource are different than what is present on the server, the resource contents MAY be slectively updated at the discretion of the server. The client needs to GET the resource if it wants to validate that all changes were made. The server responds with a 200.
d. If MORE than one resource satisying the conditional upload criterium is found, the server returns an error.
3. In a POST operation the client does not specify the logical id. The server creates the resource regardless of whether an identical resource already exists and assigns a logical id. The server responds with a 201.
In a Bundle these rules are a little different because the client may need to reference a resource in the bundle that is to be POSTed or conditionally PUT and the client does not yet have the server-assigned logical id.
Thus, in a bundle everything above applies EXCEPT for the following
1. If a resource entry method is POST or a conditional PUT, the client needs to specify the logical id if the client has any other resources in the bundle that reference this POSTed or conditionally PUT resource. The server may specify its own logical id when resolving, but it systematically changes all references to this resource in the Bundle to the new server-specified value.
I want to be sure this is correct as I was running into problems with client-specified logical ids in resource entries that were being POSTed. However, I need to specify the id since there are resources in the bundle that reference this resource.
If that is not the case, how does one solve the problem? In my case it is not so much the POST issue but the conditional update PUT where the server also creates the id. PCHA needs the conditional update PUT operation to handle the rather common problem of duplicate data being transferred from Personal Health Devices.
Grahame Grieve (Nov 20 2016 at 16:31):
#3 - well, the server may refuse to e.g. create a duplicate business id
Grahame Grieve (Nov 20 2016 at 16:32):
#1 and #2 - generally a server SHOULD update all of the resource; it can ignore some changes if it doesn't support content, but it's really wrong to ignore proposed changes and not return an error. But for various corner cases, I don't think we do (or can) make that a SHALL
Grahame Grieve (Nov 20 2016 at 16:33):
I don't see why bundles are different
Grahame Grieve (Nov 20 2016 at 16:34):
unless you are talking about a transaction where the rules are very different. But in a transaction, the bundle itself is ignored
Grahame Grieve (Nov 20 2016 at 16:34):
I don't really understand your issue
Brian Reinhold (Dec 13 2016 at 17:44):
I didn't get notified of a response so ages later I see there was one.
The difference is if I did a POST with a standalone resource, I do NOT specify the logical id
If it was in the context of a bundle I WOULD specify the logical id because I need that logical id in another resource in the bundle. That is how the case differs.
In dev days one server gave me an error because I had a logical id in an resource in a bundle that had a logical id.
Brian Reinhold (Dec 13 2016 at 17:45):
Yes I AM talking about a transaction bundle.
Grahame Grieve (Dec 13 2016 at 20:06):
so in a transaction, the bundle itself - and it's id - are ignored
Last updated: Apr 12 2022 at 19:14 UTC
