Stream: implementers
Topic: Why does FHIR have its own mimeTypes?
Natasha Singh (Oct 30 2019 at 18:34):
I’m wondering how the FHIR mimeTypes (e.g. application/fhir+json) are different from
their standard counterparts (e.g. application/json) and why they exist?
If I make a request to a FHIR server that responds with those custom FHIR mimeTypes, it won’t know what to do with the content and thus downloads the content as a file. This makes it difficult to interact with FHIR servers using browsers.
I know the spec does state: If a client provides a generic mime type in the Accept header (application/xml, text/json, or application/json), the server SHOULD respond with the requested mime type, using the XML or JSON formats described in this specification as the best representation for the named mime type (except for binary - see the note on the Binary resource). But, why not use the standard mimeTypes and then encode the fhirVersion and other fhir info in headers rather than a custom mimeType and mimeType parameter?
Lloyd McKenzie (Oct 30 2019 at 19:06):
Some servers might well be able to spit out v2, CDA and FHIR content - any of which could be XML. FHIR is aimed primarily at software, not browsers. The importance of the software understanding what type of data it's getting (and being able to ask for the type of data it wants) is more important than how nicely browsers behave with the endpoints (given that browsers are only going to be used by developers messing around testing APIs anyhow).
Gino Canessa (Oct 30 2019 at 19:08):
For JSON, there are some different rules around encoding/decoding (e.g., decimal precision in primitves).
For XML, fhir+xml contains many constraints over generic XML.
More generally, having a specific MIME type is a way of establishing the baseline for support (e.g., an implementer doesn't have to check to see if a JSON has the 'resourceType' field, deal with any other XML namespace, etc.). This is pretty useful for both clients and servers, during sending and receiving.
With all of that said, resources are generally not considered fit for human consumption, so outside of development what would be the use case?
Natasha Singh (Oct 30 2019 at 19:55):
More generally, having a specific MIME type is a way of establishing the baseline for support
I guess I was just wondering why you have to use MIME type to achieve this (a signal to implementers that the JSON/XML content adheres to the fhir spec) rather than a header.
For JSON, there are some different rules around encoding/decoding
Although there are different rules on encoding/decoding and/or different constraints on the XML, the actual content still looks to be valid XML and JSON? At first I thought the custom mimeType was an indicator of syntactically different JSON or XML
With all of that said, resources are generally not considered fit for human consumption, so outside of development what would be the use case?
Not sure, but I think it does make development harder if standard tools to view JSON/XML can't be used the way you would expect. Luckily, Postman seems to be able to intelligently interpret the application/fhir+json Content-Type (or maybe just infer based on the content itself) and still display it in JSON
Lloyd McKenzie (Oct 30 2019 at 20:32):
Mime type is how content negotiation happens with HTTP
Lloyd McKenzie (Oct 30 2019 at 20:33):
There are numerous mime types defined that are different variations of XML
Last updated: Apr 12 2022 at 19:14 UTC
