Stream: implementers
Topic: Content-Types
Josh Mandel (Apr 25 2016 at 16:45):
Does anyone think it's a bad practice for a servers to treat "Accept: application/json" (i.e. Missing the "+fhir" of the official content type) as a way for a client to ask for JSON data?
Peter Bernhardt (Apr 25 2016 at 18:30):
@Josh Mandel I don’t see a problem with a server accepting this.
Grahame Grieve (Apr 25 2016 at 19:07):
I accept it
Lloyd McKenzie (Apr 25 2016 at 20:19):
I think it would be good if the test servers spit out an operation outcome warning
Vadim Peretokin (Apr 25 2016 at 22:18):
I like it because postman has a dropdown for application/json and doesn't for application/json+fhir
Josh Mandel (Apr 25 2016 at 22:41):
Agreed, it seems like a nice convenience and it is something that I recommend to implementers that they support. Just making sure my thinking was not out of line with the rest of the community :-)
James Agnew (Apr 26 2016 at 01:03):
HAPI accepts this too..
@Lloyd McKenzie The only problem with that is that most of the places you would use the Accept: header are things that return a resource (or a bundle) so there's nowhere to put that warning.
Lloyd McKenzie (Apr 26 2016 at 01:36):
@James Agnew Is there any other way to warn implementers that they're "doing it wrong"?
James Agnew (Apr 26 2016 at 01:37):
I guess a custom header would be the obvious spot. Something like the following would be easy:
X-Warning: Content-Type for JSON FHIR content should be application/json+fhir
Lloyd McKenzie (Apr 26 2016 at 01:45):
Certainly better than nothing :)
Vadim Peretokin (Apr 26 2016 at 03:02):
I don't see a need to be honest, seems only to be a pedantic thing - there's no sideeffect that it actually warns against
Lloyd McKenzie (Apr 26 2016 at 14:00):
The side effect is that if you do this in testing and it works, that's no guarantee that it will work against real systems in production. We're trying to make our test servers a bit tighter so that client systems evolve to be more compliant
Ewout Kramer (Apr 26 2016 at 14:24):
The classic dilemma: I'm being lenient in what I accept, and precise in what I return. So, for example, I do accept _format=json as a parameter, although I probably shouldn't. But demoing a GET is much easier that way. Then again: stimulating correct behaviour by giving developers an early hint they are not doing it *exactly* right, might be a goal for the test servers.... It's going to be a balance. E.g. the discussion we're having about accepting non-xml entities is a good example of what the server probably should NOT accept.
Last updated: Apr 12 2022 at 19:14 UTC
