If you have this Y-problem,
it is wrong to return a 404 when the resource does not exist because this helps to enumerate the existing resources.
then this means you have this X-problem:
Resource enumeration should be prevented.
This in turn might affect all resources or unauthenticated resources only. In other words you might be able to mitigate the problem by requiring authentication before asking for a given resource.
Otherwise, you could make said resource difficult to guess, and implement some kind of scanner detection (simply storing what resources get 404'ed by which network for some time could be enough. You could perhaps offload the problem to an installation of
The problem as stated makes little sense because you cannot return a valid resource if an invalid one was requested - in general, you can't make up sensible, believable resources out of thin air! So there will always be a way to distinguish between resources that exist and resources that don't. Granted, supplying the information in a HTTP status header makes things simpler for the attacker, but it also makes things easier for you.
In some cases you might be able to synthesize a nonexisting resource. For example say you offer something akin to an avatar service. Then /users/lserni/avatar.png could return my picture, while /users/someoneelse/avatar.png could return a random picture generated using "someoneelse" as random seed, so that the same someone else always gets the same PNG back. But as you see, this kind of approach requires specific domain knowledge, there can't be a one-size-fits-all rule.