Support Prefer: response-async
in MedplumClient
#2237
Closed
codyebberson
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
I like the developer experience of the explicit option from (2) best: good not to force developers to pass a nested object with specific implementation detail names in it for such a cross-cutting feature. One potentially important consideration in favor of the more explicit styles is how a developer might cancel or resume a long-running poll. For example, if their application needs to be restarted in the middle of a large async operation, we would probably want to provide an easy way for them to pick back up polling rather than needing to fully retry |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
API design question:
At present,
MedplumClient
methodscreateResource
,updateResource
, andpatchResource
return the result of the operation. This provides a clean API for the common case:The client handles some special cases in update and patch, where the server returns 304 not modified, then the client returns the input, so the API contract holds.
I'm working with the Health Gorilla API, and a bunch of their FHIR endpoints require
Prefer: respond-async
. The API returns HTTP 202 "Accepted" with a "Content-Location" header.We handle a version of this in our bulk export methods (thanks @tonylee80!) But I now wonder if we should try to handle this at a more general level, because arguably any FHIR call could/should support the
Prefer: respond-async
option.Options:
a. Users can pass in
Prefer: respond-async
in the optional headersb. When
MedplumClient
sees "Accepted" and "Content-Location", it automatically starts polling and waiting for the responsec. Pros: "Easiest" for users? Everything just happens automatically
d. Cons: Too much magic? The response could take hours or more before responding
a. Similar to option 1, but users have to opt-in
a. Not all that different from Option 2, but different method would perhaps be more discoverable and less magical
b. Function signature might also be easier to digest
a. Pros: Super explicit. Supports cases where server returns "Accepted" without client opting in
b. Cons: ugly and verbose; might be an abuse of exceptions
Beta Was this translation helpful? Give feedback.
All reactions