Stream: implementers
Topic: Server response location value
Ardon Toonstra (May 01 2019 at 15:09):
Imagine posting a transaction Bundle containing some Resources types a server will not save/make available on the respective Resource endpoint. It can process the Resources but the client cannot search on it or GET even though the server successfully processes it.
The FHIR RESTful API spec states that the Server SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values.
What would the location values be of those Resources? Does it make sense to include a location for those in the response?
Michele Mottini (May 01 2019 at 15:33):
Would / should the server process a transaction containing unsupported resource? I think our reject the whole transaction in that case
Yunwei Wang (May 01 2019 at 18:34):
I guess the scenario is server supports POST on a resource type but not GET on the same type.
Ardon Toonstra (May 02 2019 at 08:02):
It is indeed the scenario Yunwei Wang describes.
Ardon Toonstra (May 02 2019 at 08:38):
So should a server if it supports POST and the resources type, create a fake location and return 403 on the location if GET is not supported?
René Spronk (May 02 2019 at 15:10):
urn:uuid:xxx ? - which is a temporary id, not something one could do a GET on.
Grahame Grieve (May 03 2019 at 08:42):
it's certainly not something we've considered. I'm not sure I follow what the use case is?
Ardon Toonstra (May 03 2019 at 08:59):
Well, it may be a bit of a theoretical use case. To provide a bit of context:
I derived a use case from the IHE MHD profile, which provides the specs for a FHIR API for XDS networks. If a FHIR client wants to send a document to a XDS network, it uses the ‘Provide Document Bundle’ transaction. The MHD spec states that the referenced Patient / Practitioner / Organization resources shall be included as contained resources in the DocumentReference. Our expectation was that this is because the server on the XDS network does not allow to GET the Patient and Practitioner resources but only the DocumentReference because the server cannot do anything with those resources in a XDS DocumentEntry. @John Moehrke
In our use case, we are sending Media resources but we do not want to use the contained resources in the Media. We do however want to take the FHIR servers on top of XDS networks into account. That raises the above-mentioned question.
Grahame Grieve (May 03 2019 at 09:34):
I haven't followed. But my response is generally the server should respond with the logical location that would apply even if the service is not available
John Moehrke (May 03 2019 at 13:39):
If you were following the MHD profile, the Media resource should cause the transaction to fail... However the problem you are describing is represented within MHD for List (Folders) Resources. MHD allows the transaction to succeed if the server is happy with everything but the Folder. This is allowed in XDS too, so this is why MHD allows it. The expectation is that this is a Transaction of a specific type, so there could be rules in that specific type of transaction implementation guide (IHE Profile... aka MHD). I expect Trial Implementation to uncover if this is a problem or not.
Last updated: Apr 12 2022 at 19:14 UTC
