A question I’ve always had about 404 and APIs...
How do you distinguish between an invalid path (no end point) and a valid path requesting a resource that doesn’t exist?
How do you distinguish between an invalid path (no end point) and a valid path requesting a resource that doesn’t exist?
I can't think for other types of not existing, or why you'd need to differentiate between them.
I call /customer/235235 and customer 235235 doesn't exist. That's a 404, resource not found.
But say I make an uncaught error with the path and call /cutsomer/235235. That also is a 404, resource not found.
It really depends on what you want the word "resource" to mean.
It gets a bit more complex if you have a simplistic website with an API service both on the same server. For your users, you want a nice 404 page for mistyped or dead links. But you don't want your API also triggering that same page.
Beyond actually splitting your main web content and API into two servers, I could see returning a 400, Bad Request response for the API to avoid triggering a 404 handler. After all if you give it a customer ID in the above case that doesn't exist, it is essentially a "bad input parameter" and the error message can indicate which parameter (the customer ID) and why it's a problem (there is no such customer).
I once worked with an old API and when a pentest team ran a scanner against it they reported hundreds of backdoors and malicious code false positives because they were expecting a 400 error rather than an 200 with success=false response body
To answer the specific question /cutsomer/123 should never be hit in a production application, unless your user actually inputs that, so treating it differently is just overhead that gives no benefit.
Also for the "both on the same server" scenario, you can make a pretty good assumption if a user agent is a browser or an API client, so you can present the right output to the right one. The accept header is the simplest method I can think of.
invalid path: 404