Auth is something different. You should return a 401 with no additional information indeed.
However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here".
> The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
If you consider the "current state of the resource" to be "it doesn't exist yet, but you could create it".
It seems useful to distinguish between requests that could be fulfilled if the database contained different things, and requests that couldn't.
Yup, that's better.
> However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here".
I suppose you can return a 403 if it's something you shouldn't be accessing, but then you're bleeding information. You're letting the client know that it exists, but they don't have permission to access it.
A scheme that checks for permissions first and defaults to 403 when they're insufficient regardless of the existence of the resource would work though.
I guess it depends on how you implement the entire system.