Wondering about Best Practices around error status codes.
I'm noticing that a lot of my "expected" return status codes like 404 are being reported as "Failed" red dots in the logs, when they aren't in fact errors, but just states that are handled by the app. (example: promo code note found results in a 404). In terms of REST, I believe this to be best practice (?), to use the status codes to represent the api status. Ideally, I'd like "Failed" to appear only for return error 500 statuses. And this would make the most sense to me anyway - why would a 404 be a typical error condition, versus just a normal state of the api?
Am I missing something? Is there a better way to do this?
3 Replies
AI Support Bot Information
<@405465071448227840> you can react on the relevant answer (message) with a ✅ in this thread when you think it has been solved, by the bot or by a human!
Anyone can react on this message with a ❌ if the GPT bot is unhelpful or hallucinating answers.
Please note: Team members will review and answer the questions on best efforts basis.
AI Response
You're right in considering that different HTTP status codes serve distinct purposes in representing an API's state. In REST, different status codes like 404 and 500 are meant for different scenarios:
- A 404 Not Found is typically used to indicate that a resource could not be found, and this is often considered a part of the normal operation of an API, especially if resources can be optionally missing or queried by users.
- A 500 Internal Server Error indicates a server-side issue that is unanticipated – a true error condition requiring attention. In your case, it sounds like you want your API monitoring and logs to handle 404 as a normal state of operation rather than an error. This approach aligns well with best practices in RESTful API design where different response codes are used to articulate the current state and success of an operation. However, if your current system flags a 404 as an error, there might need to be some configuration changes to inform the system which status codes are considered expected and not flagged as errors. This adjustment will ensure that only true server-side issues, like those indicated by 5xx status codes, are flagged for review. There might not be an exact FAQ entry on this, but making sure your logging and monitoring accurately reflect expected system behavior without false positives is indeed a good practice in API management.
- A 500 Internal Server Error indicates a server-side issue that is unanticipated – a true error condition requiring attention. In your case, it sounds like you want your API monitoring and logs to handle 404 as a normal state of operation rather than an error. This approach aligns well with best practices in RESTful API design where different response codes are used to articulate the current state and success of an operation. However, if your current system flags a 404 as an error, there might need to be some configuration changes to inform the system which status codes are considered expected and not flagged as errors. This adjustment will ensure that only true server-side issues, like those indicated by 5xx status codes, are flagged for review. There might not be an exact FAQ entry on this, but making sure your logging and monitoring accurately reflect expected system behavior without false positives is indeed a good practice in API management.
BuildShip AI Support
Would love an answer to this