Stream: bulk data
Topic: asynchronous pattern
Michael Lawley (May 11 2018 at 01:41):
The current doc for Asynchronous API indicates that it is client initiated via the Prefer: response-async header. However, is it valid for a server to initiate the protocol without that header (I very much hope so)
Josh Mandel (May 11 2018 at 07:41):
We haven't discussed this. Can you say more about why allowing this behavior would be helpful for you (as apposed to specifying that it's an error, for example)?
Grahame Grieve (May 11 2018 at 17:05):
I don't think the server should initiate this. I think we should define a clear way for the server to inform the client that it needs to make a request asynchronously
Michael Lawley (May 14 2018 at 06:19):
We have a deployment model (to enable horizontal scaling) that means all updates are queued and processed asynchronously.
This doesn't need to require a client to make the request differently; the only difference is that the response code is 202 indicating that the async protocol is in play (even if the client didn't say Prefer: response-async.
Requiring a client to make the requests "differently" (ie add the header) seems needlessly onerous, when it is only the responses that need to be handled differently.
However, just requiring servers to announce that they behave this way via something in the CapabilityStatement would be good.
Grahame Grieve (May 14 2018 at 07:04):
why should the server be able to decide that the client can handle an async redirect properly?
Michael Lawley (May 14 2018 at 09:26):
Are you suggesting that the server should refuse to accept the request then? I can understand that behaviour if the client includes the header Prefer: return=representation, but if the client expresses no explicit preference, then why can't the server choose what best suits it?
Josh Mandel (May 14 2018 at 09:51):
When you add an item to your queue, do you return a Location header with the location where the resource will appear?
Josh Mandel (May 14 2018 at 09:52):
Just trying to assess how much your server follows the rules for "a FHIR REST API server". The current FHIR definition is a bit limited / doesn't anticipate async creation. E.g. it says:
SHALL also return a Location header
Michael Lawley (May 14 2018 at 10:37):
We can return either a Location URL for status of the queue entry or for the eventual location of the created resource (since that is determined before the request is enqueued)
We're not sure which would be better
Michael Lawley (May 14 2018 at 10:38):
Most of these things will be processed very quickly, so it's probably not worth the client being forced into a poll for the result type of interaction
Last updated: Apr 12 2022 at 19:14 UTC
