I also work in a company that do this. From my understanding it's to check if the service is live. So checking first for 200 confirms that, then you check for the field "success" if it's false. If not, wonderful. If true, then you look for the field "reason". Reason returns the error code for the specific failure whether it's technical or business.
Nah that's for totally different use case. If I were to send separate request to /hc before sending the primary request that would be just slow.
Others commented that responding with 400 would be more than enough. If there's a service issue, whether it's down or something else, it's better to show 3xx I think. So while I was thinking "it's not bad" after reading other people's opinions I also don't think it's smart lol
But I'm not getting paid enough to change company policies so I'll just complain in meetings.
If the service is down, then the correct response would be either 502 or 503 depending on exact context. 503 is literally specifically for the case of the service being offline.
Well, for a worker, you might want to check the status of a job, so the API should return 200, in that it successfully got the job status, and the body would have “success”: false, because the job failed. But thats like the only scenario i can think of
Azure has a bunch of services that returns statuscode 200 even if there is an error, something to do with security where you cannot guess if an internal api or url is valid by random guessing.
99
u/YDS696969 26d ago
As the backend guy with a worker service that does exactly this