401 Unauthorized
It occurs when access to the server resource requires authentication - through the header WWW-Authenticate
- and this failure for some reason (lack of credential or invalid credential). Client trying to connect server can try a new request with a more appropriate credential. If a new attempt is made by the same agent with the same credentials the server must provide more relevant information for the user to understand what is happening.
The semantics to be understood here is that valid authentication is missing, that’s all.
403 Forbidden
It occurs when the server refuses to grant the request because of some rule that determines the denial of access. The client should not try again even with credentials since the denial did not occur because the client failed, nor for something that can be solved on the server on its own. The server can give further information if the attempt is made with a method HEAD
. This information must describe the reason for the denial. If he does not wish to give more information then the error code to be exchanged by 404 Not Found
.
The semantics here is that no independent access authorization has been given.
Source.
Though I’m not strictly correct according to RFC, some servers are configured to only respond 404 Not Found
in either case. This follows the principle of obscurity.
If you consider that authentication via HTTP has fallen out of use in most applications; and that knowing if the resource does not exist or you can not access, in the background gives in the same; in a pragmatic approach it makes sense to set aside these two error codes.
Of course there may be cases to use the recommendation but you need to know when. The creative and responsible use of the codes is not something inherently bad. REST is a case where one uses a lot, and there are endless discussions about which one to use in each case.
+1 by question. I have the same doubt :)
– Wallace Maxters