Why even use HTTP, when you can just send bytes directly over the physical network card, right?
Because standards make it better for everyone. You’ve no idea when, who or in what context the error will happen or be received by.
It takes so little to return ProblemDetails, and improves the experience of devs using your API so much. Just do it. Stop thinking up edge cases and faffing about with excuses. Do it.
Please, please, please, PLEASE return error-codes and problem-details.
Here’s the RFC: https://www.rfc-editor.org/rfc/rfc9457.html
It’s often valid to serve a 200 OK with an error in the application data.
Valid, but dumb.
Counter argument is that error codes and problem details can be used by attackers to reverse engineer and find exploitable parts of a system.
Within reason anyways
So can a 200 response with an error description
This looks so over-engineered. Most of the time you only need an error message. Make the message clear enough so that it can be shown to the end user.
Why even use HTTP, when you can just send bytes directly over the physical network card, right?
Because standards make it better for everyone. You’ve no idea when, who or in what context the error will happen or be received by.
It takes so little to return ProblemDetails, and improves the experience of devs using your API so much. Just do it. Stop thinking up edge cases and faffing about with excuses. Do it.