FHIR Chat · Search using POST: 200 or 201? · implementers

Stream: implementers

Topic: Search using POST: 200 or 201?


view this post on Zulip Alexander Henket (Jan 30 2020 at 11:12):

If POST is the HTTP verb for creating resources and normally leads to status 201 if successful, and I use POST for search: couldn't that lead to a status 201 instead of 200? (https://www.w3.org/Protocols/HTTP/HTRESP.html)

Apparently you can distinguish between cacheable search versus non cacheable search (e.g. https://stackoverflow.com/questions/42464409/is-it-correct-to-return-200-ok-http-status-for-a-post-request). Cacheable search is considered to "create" a search resource, hence 201 would be appropriate.

Since FHIR explicitly documents 200 for search (http://hl7.org/fhir/http.html#summary): is it wrong to respond with 201?

view this post on Zulip Richard Kavanagh (Jan 30 2020 at 12:14):

I don't see how a search executed via a POST can create anything, as such a HTTP 201 doe snot appear to be an option. As there is nothing is created there is no ability to return details of the "newly created document".

view this post on Zulip Alexander Henket (Jan 30 2020 at 15:55):

I was in a meeting with 20 architects who argued differently. At least a cached query would conceptually instantiate a query resource, server side. Hence 201 is warranted in their view. Must admit I had never heard of that viewpoint. Just echoing how they saw it.

view this post on Zulip Vassil Peytchev (Jan 30 2020 at 18:33):

Wow...


Last updated: Apr 12 2022 at 19:14 UTC