Stream: implementers
Topic: mimetypes
Jens Villadsen (Apr 06 2017 at 12:29):
Is curl a valid fhir client? Meaning that issuing an request that looks like this: http://1.1.1.1/Patient?family=MOORE&given=CHIP with the acceptheader set to */*?
Jens Villadsen (Apr 06 2017 at 12:30):
@Paul Lomayesva
Michele Mottini (Apr 06 2017 at 18:12):
Not 100% sure of what are you asking, but some FHIR server are picky about the Accept header - .e.g. the Cerner FHIR server wants application/json (or application/fhir+json)
John Moehrke (Apr 06 2017 at 19:04):
in theory you dont need to specify which kind of encoding you want returned (aka */*) ,but then you are at the whim of the server. Some might chose json, some might chose xml, some might chose turtle, some might chose html rendered, etc... the whole purpose of accept headers is to provide preference. Use the _format if you can't affect the accept headers .
Joel Schneider (Apr 06 2017 at 21:00):
This kind of thing has worked for me before.
curl --silent --show-error --data \@fhir-bundle.xml --header "Content-Type: application/fhir+xml" http://localhost:8080/baseDstu3
Grahame Grieve (Apr 06 2017 at 21:47):
I don't know what my server would do with an accept like that - it's never occured to me test it. But John is right
Jens Villadsen (Apr 07 2017 at 09:01):
curl was just an example. I get that the server can respond in any format that it favours, and thats the whole point. If my client really supports any kind of format (ie. turtle, json, html, xml, whatever) is it still considered a valid request? I'm asking because of course */* contains all types, but its use/validity is not stated on http://build.fhir.org/http.html#mime-type
Jens Villadsen (Apr 07 2017 at 09:58):
What is stated is 'The correct mime type SHALL be used by clients ... ' - I would claim that since */* is all mime types, it is correct
Grahame Grieve (Apr 07 2017 at 10:39):
well, it's not wrong. But it's not what the standard describes, so outcome is unpredictable
John Moehrke (Apr 07 2017 at 11:51):
Jens what is the problem you see? We have expressed that it is not wrong, and the outcome is in the hands of the server. I think getting more prescriptive is not helpful, and could be fragile too.
Jens Villadsen (Apr 07 2017 at 21:59):
The problem as I see it is that the standard in its wording is too restrictive on this point. The phrase "The correct mime type SHALL be used by clients and servers:" (and then the mime types are listed) is not necessary as it leaves little room for using e.g. */* as an accept-header from a client that is willing to accept whatever format is returned. Also, as it is stated afterwards "Servers SHALL support server-driven content negotiation as described in section 12 of the HTTP specification." basically means that */* is acceptable as accept-headers MAY be used to assist the server. I just tried a request against the HAPI implementation and it default back to json, but does that mean that the HAPI implementation violates the standard? IMHO, I think not
Grahame Grieve (Apr 09 2017 at 02:41):
what that means is that implementations (particularly servers) have know and use the right MIME types for FHIR resources. It wasn't meant to exclude doing things like */* for accept. You could create a task to calrify.
John Moehrke (Apr 09 2017 at 16:45):
Jens, if */* is what the client system sees as 'correct', then it is correct.
Jens Villadsen (Apr 09 2017 at 21:29):
@John Moehrke - not the way I'm reading the standard the way it is written right now. @Grahame Grieve I'll submit a task
Last updated: Apr 12 2022 at 19:14 UTC
