Think the point would be that it’s super easy to also set a ‘non-ok’ status in HTTP. Sure it may be insufficient for sophisticated handling, but at least you can get a vague sense of ‘something went wrong’…
Sure have your more specific API specific error code and your error details in the body, but at least toss a generic ‘500’ into the status code. I often find myself writing client software where I don’t need specific handling I just need to know ‘it failed’, and it’s obnoxious to deal with these interfaces where I have to sweat multiple potential ways for it to report failures when I just don’t care about the specifics. Sometimes an API doesn’t even have a consistent place that it sticks it’s return code, some don’t even define a reasonable way to know ‘failure’ and require you to explicitly map a huge number of ‘info’ to ascertain if it’s normal or error type state.
Think the point would be that it’s super easy to also set a ‘non-ok’ status in HTTP. Sure it may be insufficient for sophisticated handling, but at least you can get a vague sense of ‘something went wrong’…
Sure have your more specific API specific error code and your error details in the body, but at least toss a generic ‘500’ into the status code. I often find myself writing client software where I don’t need specific handling I just need to know ‘it failed’, and it’s obnoxious to deal with these interfaces where I have to sweat multiple potential ways for it to report failures when I just don’t care about the specifics. Sometimes an API doesn’t even have a consistent place that it sticks it’s return code, some don’t even define a reasonable way to know ‘failure’ and require you to explicitly map a huge number of ‘info’ to ascertain if it’s normal or error type state.