FHIR Chat · Incorrect meta-data returned on PUT? · hapi

Stream: hapi

Topic: Incorrect meta-data returned on PUT?

view this post on Zulip Morten Ernebjerg (Dec 12 2018 at 08:41):

I've noticed a somewhat confusing behavior with the way HAPI updates meta-data upon PUT (also reproducible on http://hapi.fhir.org/baseDstu3) and just wanted to check that I am not missing smt. before I log an issue. Specifically, the lastUpdated and versionId fields do not seem to be updated synchronously.

Suppose we do the following

1. First, POST a resource --> get back created resource with lastUpdatedand versionId
2. Copy the resource returned, make a change somewhere, and then PUT it, including meta-field --> get back (apparently) updated resource with lastUpdatedand versionId
3. Finally, GET the resource

Then we find that:

  • The resource returned from the PUT in step 2 has an updated lastUpdated relative to what came back from the POST in step 2, but the same versionId (viz. the one that included in the body of the PUT request).
  • In step 3, we get back a resource in which both versionId and lastUpdated`has been updated.

In other words, the resource returned on a PUT seem to have a "half-updated" meta-field. However, the ETag header has the correct version. There is also a Content-Locationheader with the correct versioned path, but no Locationheader. Also, if we leave out the meta-field in the body of the PUT in step 2, the right (updated) versionId comes back in response(in line with the spec: "If the request body includes a meta, the server SHALL ignore the provided versionId and lastUpdated values".

Is there some reason behind this behavior? From the spec it seems that returned the updated resource is not required, only the updated ETag.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -