Stream: implementers
Topic: Empty search parameters
Mathias Svendsen (Dec 13 2017 at 13:17):
Noobie here:
Say I make a search along the lines of 'GET [base]/Observation?subject=,code=whatever' (with an empty subject-parameter), what would the expected response be?
Do I throw an error, since searching for nothing does not make sense?
Or should I return an empty set, since I have no observations with the subject in the empty list?
Or do I return all observations where subject is missing?
I know hapi just tosses the empty parameters away before they even hit the server, but I was wondering what the fhir spec has to say on the matter, and I could not find anything about it in https://www.hl7.org/fhir/DSTU2/search.html#errors
Christiaan Knaap (Dec 13 2017 at 13:19):
Elements are not allowed to be empty, so searching for it also makes no sense. If subject (in this case) is to be empty, it should not be in the resource altogether. And you can search for that: /Observation?subject:missing=true
Christiaan Knaap (Dec 13 2017 at 13:20):
BTW: Your example contains another error: the comma should be an ampersand:
GET [base]/Observation?subject=&code=whatever
Mathias Svendsen (Dec 13 2017 at 13:22):
Roger, so I just return an OperationOutcome in which I yell at the client for trying to do that? :-)
Christiaan Knaap (Dec 13 2017 at 13:26):
You could also tell the client politely, but yes, that is the correct answer :-)
Lloyd McKenzie (Dec 13 2017 at 15:54):
There are a lot of UIs that display a list of search criteria for you to search on and then generate the search string by concatenation, so seeing ...?subject=&code=foo is pretty common. I know Grahame's server ignores parameters without a value. If you wanted to search for elements where the value was missing, you'd do subject:missing=true
Grahame Grieve (Dec 13 2017 at 19:17):
a search with no criteria is a request to list all resources of the specified type. The public servers generally just go ahead and list all the resources... but server are not required to implement this, and should return an error if they do not
Lloyd McKenzie (Dec 13 2017 at 20:45):
@Grahame Grieve The question is what to do with a parameter that's listed but provides no value
Grahame Grieve (Dec 13 2017 at 20:57):
ignore it.
Lloyd McKenzie (Dec 13 2017 at 22:31):
Do we state that explicitly in the spec anywhere?
Grahame Grieve (Dec 13 2017 at 22:32):
apparently not. Surprisingly. but it's very definitely the case, based on how HTML forms work
Lloyd McKenzie (Dec 13 2017 at 22:39):
@Mathias Svendsen Would you be willing to submit a change proposal? Just click on the "Propose a change" link at the bottom of any page in the spec. You'll need to register (which sometimes takes a day or two as HL7 HQ tries to confirm that you're a real human being and not a viagra sales person), but after that you can submit as many change proposals as you like. And you'll be officially elevated from being a "Noobie" :)
Mathias Svendsen (Dec 14 2017 at 13:14):
Ignoring search params seems like a bad thing - that's what prompted me to ask here. If i, say ask for all observations for a patient, and the list of patiens is accidentally empty, the server would take quite a performance hit if it was expected to just return everything. Personally I like either the error-option or the empty-result-option.
Any way, i'll propose a change, to officially be un-noobie-fied
Lloyd McKenzie (Dec 14 2017 at 15:42):
The server has the right to reject a query without a minimum number of search parameters, to cap the number of rows contained or to throw a "too costly" error. Ignoring search parameters will be pretty common - systems can also ignore search parameters they don't support even if data is specified. It's the responsibility of the client to look at the "self" link to see what search parameters were actually used.
Christiaan Knaap (Dec 18 2017 at 10:02):
Indeed it is not explicitly in the spec. I interpreted this as a special case of 'Unknown and unsupported parameters' (http://build.fhir.org/search.html#errors), since a parameter without a value is unsupported by Vonk. We ignore it but include a warning in the OO in the response bundle.
Grahame Grieve (Dec 18 2017 at 10:29):
pre-applied this note:
Note: Empty parameters are not in error - they are just ignored by the server
Lloyd McKenzie (Dec 18 2017 at 15:44):
"an error" would read slightly better than "in error"
Last updated: Apr 12 2022 at 19:14 UTC
