Maybe "more RESTFully" logic may be:
return 401 if user unauthenticated (it's does not matter exists account or not);
return 403 if user authenticated but is not owner of requested account (it's does not matter exists account or not);
return 404... I think never :)
If there is no authentication in API, and we want to protect our growth rate statistics - yes, same problem exists. And GUID instead of INT identifiers may help.
Even if there is authentication in API, it doesn't matter. (See Panera's "fix")
GUID or other unpredictable identifier is the only real fix. Rate limiting each user can help as well, but how useful that is really depends on how hard it is to get authentication tokens.
Maybe "more RESTFully" logic may be:
return 401 if user unauthenticated (it's does not matter exists account or not);
return 403 if user authenticated but is not owner of requested account (it's does not matter exists account or not);
return 404... I think never :)
That has the exact same problem as 401 / 404, it just requires the the additional step of registering. There is little to no security gain.
If there is no authentication in API, and we want to protect our growth rate statistics - yes, same problem exists. And GUID instead of INT identifiers may help.
Even if there is authentication in API, it doesn't matter. (See Panera's "fix")
GUID or other unpredictable identifier is the only real fix. Rate limiting each user can help as well, but how useful that is really depends on how hard it is to get authentication tokens.
That certainly makes sense.