Stream: implementers
Topic: HTTP codes vs. OperationOutcome
Tim Berezny (Apr 11 2018 at 13:41):
In the FHIR world, is there a preferred approach to handle error codes?
One approach we're looking at is always providing HTTP 200 OK, and putting all of our errors (like bad credentials, bad formatted payload, etc...) into the operationOutcome response.
We're also considering using a limited set of HTTP codes in addition to operationOutcome
200 (OK) - Successfull request
400 (Bad Request) - There was a problem with the API request
500 (Internal Server Error) - There was a server side issue. Try the request again and/or report the issue to Caredove.
401 (Unauthorized) - There is a problem with the user's credentials
403 (Forbidden) - The request is attempting to access a resource beyond the scope of its credentials
404 (Not Found) - A requested or referenced resource cannot be found
Grahame Grieve (Apr 11 2018 at 13:42):
http://build.fhir.org/http.html#summary - summarises the error codes. in some cases, returning the correct code is required, not optional . In other cases, your discretion applies
Grahame Grieve (Apr 11 2018 at 13:43):
but there is a rule that you SHALL not return an OperationOutcome that contains errors with a 200OK http response
Tim Berezny (Apr 11 2018 at 13:59):
Thanks @Grahame Grieve
John Moehrke (Apr 11 2018 at 14:04):
for example: In some of the IHE profiles (Implementation Guides) we have identified for very specific warnings/errors more exacting ways to use the OperationOutcome and http to more consistently drive the way that specific error condition is handled. We never contradict the core requirements from FHIR http, but have found it useful to be more specific when there is a specific expectation driven by the use-case analysis and the guidance given.
Tim Berezny (Apr 12 2018 at 13:38):
Thanks @John Moehrke , that's good to know. That feels like the right way to go...
Last updated: Apr 12 2022 at 19:14 UTC
