-1

In working with my company's web API as well as the APIs of others, I've always thought that a response code of 500 should only be returned in case of an actual server bug. If I, the user, made an error in the call, there are the 4xx codes; whereas a 500 indicates that there was nothing wrong with my call, but the server can't figure out what to do, and may even have hit an exception while handling my request. A 500, I've insisted, should be logged server-side and corrected.

But am I wrong? Are there appropriate uses of the 500 response code? In particular, are there cases where it makes sense to consistently return a 500 without correcting the condition that led to it?

To put it another way, when I use our company's API and get a 500, my reaction (as an automation developer) is "Fix the bug."

What uses of 500 are there that don't involve a bug to be fixed?

Ryan Lundy
  • 204,559
  • 37
  • 180
  • 211
  • Does this answer your question? [When should I return HTTP Status Code 500 (Internal Server Error) from REST application to client?](https://stackoverflow.com/questions/42409241/when-should-i-return-http-status-code-500-internal-server-error-from-rest-appl) – jonrsharpe Jul 08 '21 at 12:02
  • See also e.g. https://stackoverflow.com/q/18709834/3001761, https://stackoverflow.com/q/39636795/3001761 – jonrsharpe Jul 08 '21 at 12:03
  • @jonrsharpe I've edited to elaborate a bit. I've seen those questions and others, but the trouble I'm having is that anything I find about when to use the 500 is full of hand-waving generalities, not specific examples. That last question with the flowchart was a bit better, but the final condition to choose between 500 and 501 made no sense to me. "Do you feel bad...?" What's that about? – Ryan Lundy Jul 08 '21 at 12:56

1 Answers1

1

A 500 status is more or less a catch-all status for any server-specific issues which may prevent the server from performing the request. If there is a ore specific error code available, servers may use those or could (for various reasons) decide to just use the catch-all 500 status code.

The status code alone does not indicate whether the error is permanent or temporary or under which circumstances it was caused. While servers may provide additional information (such as the kind of error or a possibly retry interval), there is no common standard to express this. Instead applications may chose appropriate message formats.

As such, while a 500 status is often send in response to an otherwise unhandled exceptional situation on the server-side which could not be handled in a more appropriate way, depending on the application it may also be send deliberately. The specific semantics here are up to the application.

Holger Just
  • 52,918
  • 14
  • 115
  • 123