The immediate rebuttal to this whole article is that you can have custom response bodies on any status code, not just when the status code is 200, so you can sa

The immediate rebuttal to this whole article is that you can have custom response bodies on any status code, not just when the status code is 200, so you can satisfy both kinds of users by having `/api/v1/employees/100` with `404` as the status code and `{ "success": false, "reason": "No employee with ID 100 exists" }` while `/api/v11/employees/1` can fail with `404` as the status code and `{ "success": false, "reason": "No such path: /api/v11", }` Now for those who are exploring your API with curl or are reading logs from their service they can see the human-legible information that may help them debug the error, while their application logic can continue to use `2xx` for success, `4xx` for my own failure and `5xx` for a server failure that I should retry after some back-off time, allowing it to do the most sensible thing it can in the situation, rather than explode in an uncontrolled fashion when an endpoint the developers only got successful 200 responses from during development suddenly encounters a 200 response with an error payload.