Clarify Binary behavior for application/fhir content.

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Binary
    • Hide
      • Clarify what happens when the client does request a binary explicitly using the FHIR content types: wrap the binary data in a Binary resource and return that in the requeste xml/json format. Even when the binary data itself is FHIR data.
      • This behaviour is only applicable for the explicit FHIR mime types, not the more general xml/json types.
      • _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.
      Show
      Clarify what happens when the client does request a binary explicitly using the FHIR content types: wrap the binary data in a Binary resource and return that in the requeste xml/json format. Even when the binary data itself is FHIR data. This behaviour is only applicable for the explicit FHIR mime types, not the more general xml/json types. _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.
    • 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.

            Assignee:
            Unassigned
            Reporter:
            Elliot Silver
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: