-
Type:
Change Request
-
Resolution: Persuasive
-
Priority:
Medium
-
FHIR Core (FHIR)
-
STU3
-
FHIR Infrastructure
-
Binary
-
-
Richard Ettema/Yunwei Wang: 4-0-0
-
Enhancement
-
Non-substantive
-
STU3
The Binary resource contains the following statements:
"Binary resources behave slightly differently to all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly."
"When a binary is written the server (create/update - POST or PUT), the data is accepted as is and treated as a the binary content of a Binary, including when the content type is "application/fhir+xml" or "application/fhir+json", except for the special case where the content is actually a Binary resource."
It would be helpful to be more explicit that if the created content is application/fhir+xml or application/fhir+json, then there is no standard way to get that content back directly. For all other mime types, I get back the content I put in, however for FHIR mimetypeAn attempt to retrieve the content would result in getting it back wrapped in the Binary. (Hmm, what should I get back if I ask for application/xml content?) Also, content posted as application/fhir+xml, and retrieved as application/fhir+json, would get back the Binary in JSON representation, but the contained content would still be in XML.
Alternatively, it might be useful to define a standard operation, query parameter, or HTTP header that can control whether you want the Accept header/_format query parameter to apply to the Binary resource or to the contained content. It is unclear whether such a operation/query-parameter/header should apply to all Binary resources or only to Binary resources containing FHIR content.