> Why do I get a 404 here? > [...] > As an API consumer, all I want to do here is raise my middle finger. Why? As an API consumer this makes sense to me. The

> Why do I get a 404 here? > [...] > As an API consumer, all I want to do here is raise my middle finger. Why? As an API consumer this makes sense to me. The author doesn't go into any detail on why it presumably doesn't make sense to them, nor what problems it presents from a client implementation standpoint? > RFC 7230 defines HTTP as an Application Layer protocol, which means it should represent application logic, right? No. What? No. Why on earth would it mean that. It's a protocol at the application layer - it has nothing to say or do w.r.t. the internal implementation details of that application. Why on earth would it? None of this article makes any sense whatsoever. The author is making some wild assumptions that seem entirely unique to themselves - I've certainly never seen anyone else face these logical challenges. > In any API call, there are 2 problems to solve as a client when you are processing the response: > 1: Did the technical request succeed? > 2: Did the business/domain request succeed? Where in your client code are you trying to solve these problems? Is it in the same place? If so, you've over-generalised / over-DRY-ed your error handling. If you've approached writing your client in a sane manner, you have business/domain context at the request site - you can tell the granularity of your request validity by the code location where you're handling the response. As a developer of client code, 4xx means "I did something wrong". It's not the server's responsibility to know how I've implemented URL-building and whether or not I'm using dynamic version strings. Take the author's example: /api/v1/employees/100 -vs- /api/v11/employees/1 Here's 2 ways I could build that URL (pseudocode): base = '/api/v1' section = '/employees' url = '$base/$section/$id' v = '1' url = '/api/v$v/employees/$id' The author's assuming something like the 2nd way, and supposing the API should be aware your client code could have supplied an invalid value for $v. But what if it's the 1st and you've supplied an invalid value for $base? Expecting knowledge of your client implementation on the side of the API implementers is nonsense. --- As for the solutions proposed, there's two problems: Problem 1 (harmless enough): The error context provided in the 200 response body will only be specifically useful for the author's example client implementation - many different clients will consume your API and their implementations will differ. For some of them, the context will be of less/no use (coupled with added developer confusion from the unexpected statuscode). Problem 2 (harmful): This kind of context is going to enable OSINT user & metadata enumeration in a very large number of API applications, so recommending this as general advice is actively dangerous.