Stream: implementers
Topic: search results in empty set
John Moehrke (Feb 10 2017 at 13:32):
For the case where a request is proper, but for which zero results are found. Should we have defined results? This is not an access control restriction, the requester is authorized. This is not a wrong URL. This s a case where the query is fully proper, there is simply no results available for the query parameters. It seems some return 200 with an empty result, others return 404. Both cases seem to have OperationOutcome. But I am looking for guidance on the http error code.
Arianne van de Wetering (Feb 10 2017 at 13:49):
My vote would be: 200 (success) with an empty result.
This is also what has been agreed to do on the Dutch national infrastructure (LSP - Landelijk Schakel Punt)
Richard Ettema (Feb 10 2017 at 13:58):
The specification defines the following behavior for a successful search operation [see the spec at http://build.fhir.org/http.html#search]:
If the search succeeds, the return content is a Bundle with type = searchset containing the results of the search as a collection of resources in a defined order. The result collection can be long, so servers may use paging. If they do, they SHALL use the method described below (adapted from RFC 5005 (Feed Paging and Archiving ) for breaking the collection into pages if appropriate. The server MAY also return an OperationOutcome resource with additional information about the search; if one is sent it SHALL NOT include any errors, and it shall be marked with an entry mode of include.
(My interpretation) The inference for the returned HTTP response code is a 200(OK) - success with a payload. The last part describing the optionally returned OperationOutcome in my opinion does not fully define where the OperationOutcome is to be defined but, again by inference, I would say the OperationOutcome is returned as the only entry in the searchset Bundle. (Sounds like we need a gforge tracker to resolve this clarification.)
Richard Ettema (Feb 10 2017 at 14:15):
So, based on what I'm reading in the spec today, I would define a test case for the scenario of "a search operation that is expected to return no matching entries" with the following minimal assertions:
- HTTP response code = 200(OK)
- Response payload contains a FHIR Bundle resource type
- Bundle.type = searchset
- Bundle.total = 0 (if no OperationOutcome returned in Bundle.entry - need clarification to verify this behavior)
Richard Ettema (Feb 10 2017 at 14:15):
(comments and feedback welcomed)
John Moehrke (Feb 10 2017 at 18:16):
We have had about 50% people who choose 200, while others use 404. This is even true of the current FHIR servers available for testing... So it seems it is not obious
Richard Ettema (Feb 10 2017 at 18:41):
Ok. I just created tracker #12815 requesting clarification of the required behavior for a successful search response.
Lloyd McKenzie (Feb 10 2017 at 20:55):
Wow, I was sure this was documented, but apparently not. Correct answer is absolutely a 200 with an empty searchset Bundle. We use 404 if you do a read and the specified id doesn't exist, but not for a search
Richard Ettema (Feb 10 2017 at 20:58):
Can we get #12815 triaged and updated with the clarifications to apply to the spec?
Lloyd McKenzie (Feb 10 2017 at 21:08):
Done. We actually need guidance on HTTP codes for for PATCH. And it might not be a bad idea to note that 404 is appropriate for delete and may sometimes be appropriate for update?
Richard Ettema (Feb 10 2017 at 21:23):
I also just added my proposed updates to the search definition. Please review when you have a chance. Thanks.
John Moehrke (Feb 14 2017 at 16:53):
Thanks. I will have IHE follow our resolution of GF#12815
Last updated: Apr 12 2022 at 19:14 UTC
