Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Direct Upload and Download of Binary Content at the Binary Endpoint #2009

Open
2 tasks
schwzr opened this issue Sep 4, 2024 · 0 comments
Open
2 tasks
Assignees
Labels
epic A large body of work that can be broken down into a number of smaller issues. module:rest-api
Milestone

Comments

@schwzr
Copy link

schwzr commented Sep 4, 2024

As part of MII's data transfer projects, some binary resources will probably have to be created on the FHIR servers. Therefore, it would be advantageous if this could be done as simply as possible and without “wrapping” in Base64 and JSON / XML resources.

The FHIR specification defines the REST API for Binary resources.
It allows binary resources to be created and read by sending only the content to the FHIR server via the HTTP body, and to be read by sending a non-FHIR Accept header.

Specifically, the following should apply to the binary endpoint:

General

  • The Binary resource is always represented in the native FHIR format when wrapped in a Bundle.

  • The _format overrides the accept header and SHALL be interpreted as using the standard FHIR mime types, even if the more generic mime types are given as a value.

  • due to the way the web infrastructure works, it is not possible to make blanket rules about the relationship between the "Accept" field in the HTTP request, and the return type, which is why there is no hard rule about this. However, the intent is that unless specifically requested, the FHIR XML/JSON representation is not returned.

Download

  • Implement Direct Upload of Binary Content at the Binary Endpoint #2126

  • When a read request is made with a FHIR type in the Accept header (e.g. "application/fhir+xml" or "application/fhir+json") the binary resource is returned in the requested FHIR format. This applies even when the binary data itself has a FHIR mime type.

  • When the read request has some other type in the Accept header, then the content should be returned with the content type stated in the resource in the Content-Type header. E.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly. The _summary parameter does not apply in this case.

  • Note that when client requests a Binary resource using a generic mime type (application/xml, text/xml, or application/json), the server SHOULD return the content directly if the content-type format matches the requested mime type (e.g. if the Accept header is application/json, and the contentType is vnd.xacml+json). However, servers might not always be able to interpret mime types correctly, and clients SHOULD be prepared to receive either format.

Upload

@alexanderkiel alexanderkiel added the enhancement New feature or request label Sep 10, 2024
@alexanderkiel alexanderkiel added this to the v0.31.0 milestone Sep 10, 2024
@alexanderkiel alexanderkiel added epic A large body of work that can be broken down into a number of smaller issues. and removed enhancement New feature or request labels Oct 8, 2024
@alexanderkiel alexanderkiel modified the milestones: v0.30.1, v0.31.0 Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic A large body of work that can be broken down into a number of smaller issues. module:rest-api
Projects
None yet
Development

No branches or pull requests

3 participants