Stream: implementers
Topic: When an invalid query parameter variable is attempted...
Michael Cox (Jun 02 2020 at 17:26):
...why does my R4 Azure API for FHIR return instead a general query for the resource and ignore the invalid query parameter? Should the response not be a rejection for invalid query variable?
My situation in a bit more detail:
- The mistaken query variable: I was trying to send a GET req for " [Base URL]/QuestionnaireResponse?reference=#### ", when in actuality I should have been querying for " [Base URL]/QuestionnaireResponse?identifier=#### "
- When I sent this incorrect URI to the backend, instead I was returned a 200 but for a general query on the resource (as if I sent a GET to " [Base URL]/QuestionnaireResponse" which effectively gave me all of the available resources. I understand how this would be a super useful feature in most scenarios, but for mine it would be preferred to only return the query I sent or otherwise a 404/500 response.
I guess my main two questions are: Is this standard for Azure API for FHIR? && Are there additional variables I can add to my query URI to perhaps ensure my desired return flow?
Thanks as always for the great insight all. Look forward to hearing from the community
Lloyd McKenzie (Jun 02 2020 at 17:36):
Ignoring unsupported search parameters is the standard (and recommended) server behavior because it's more efficient. If it failed, the client would have to reformulate the query to exclude the unsupported parameter (and write and test the complex code to handle that), then re-query and filter the data locally. The default mode of just filter with what you can means the only code the client needs to write is to filter the data locally. The server always declares what parameters it paid attention to.
Paul Church (Jun 02 2020 at 17:48):
In my experience most developers have found this behaviour confusing and frustrating, so we added a configuration option to the Google FHIR store to enforce strict handling by default.
Lloyd McKenzie (Jun 02 2020 at 17:50):
It sort of depends on whether you're developing a client for a single server or for a variety. The API is optimized for those who are developing for a variety.
Michael Cox (Jun 02 2020 at 18:07):
@Lloyd McKenzie Thank you for the valuable insight.
@Paul Church thanks for your perspective as well, this discussion was helpful.
Yunwei Wang (Jun 02 2020 at 18:45):
@Michael Cox You can add this to indicate client's preference. Again, depends on if server supports that.
Prefer: handling=strict: Client requests that the server return an error for any unknown or unsupported parameter
Michael Cox (Jun 02 2020 at 18:54):
@Yunwei Wang Ah interesting. Sorry, is that a header or something in the param you are describing?
Chris Moesel (Jun 02 2020 at 19:06):
@Paul Church -- in my opinion, it's not only "confusing and frustrating" for a server to ignore unsupported query parameters; I believe it's dangerous (at least in the healthcare domain). If a server can't properly provide what a client asked for, it should be very clear about that. But... I've argued for this before and haven't won yet. ;-)
Jenni Syed (Jun 02 2020 at 20:05):
R4 added the pref so a client could describe the behavior, as mentioned above. It still gets interesting on if you fail for "known unsupported" vs. others you don't know about (that may be added by network or things between)... Also apps can query the params as described in the conformance statement vs. discovering late/after sending the req
Jenni Syed (Jun 02 2020 at 20:06):
could be done at the same time it discovers if the resource/action is supported at all by the server.
John Moehrke (Jun 02 2020 at 20:10):
Chris Moesel said:
Paul Church -- in my opinion, it's not only "confusing and frustrating" for a server to ignore unsupported query parameters; I believe it's dangerous (at least in the healthcare domain). If a server can't properly provide what a client asked for, it should be very clear about that. But... I've argued for this before and haven't won yet. ;-)
The theory is that a server ignoring a query parameter will ONLY have the affect of returning MORE results than the client is expecting. Meaning that query parameters only constrain the results, not expand the results.
Chris Moesel (Jun 02 2020 at 20:31):
Understood. It's just that more results isn't necessarily safer. Consider /Condition?verification-status=confirmed for a server that doesn't support searches via verification-status -- you might get some Conditions that are refuted or entered-in-error. Quite the opposite of what the client wanted!
I do appreciate that there are provisions for clients to pro-actively say they don't want it this way, or to check conformance for what is supported; I just feel like we should have defaulted to the safer approach rather than requiring "opt in" to the safer approach. Unfortunately, I don't think every developer reads enough of the spec to understand that servers can silently ignore their spec-valid search parameters and that they (the client) need to defend against that. But... I think that's all normative now, so I'll try to stay quiet. ;-)
Lloyd McKenzie (Jun 02 2020 at 20:34):
There are lots of situations in RESTful spaces where additional parameters end up in the URL for transport reasons. Failing based on the presence of those would be quite problematic.
Lloyd McKenzie (Jun 02 2020 at 20:35):
The spec is quite clear that implementers SHALL check the self link of query responses and handle the situation of data not being filtered as much as they might wish.
Brian Postlethwaite (Jun 26 2020 at 08:13):
I have a server that only rejects if you don't have specific search params in specific contexts.
Last updated: Apr 12 2022 at 19:14 UTC
