If the client provides the appropriate credentials (e.g., a valid access token), its request is accepted and processed. Let's consider the case when a client attempts to call a protected API. In summary, your Web API's response should provide the client with enough information to realize how it can move forward opportunely. Similarly, when the client receives a 500 Internal Server Error status code, it knows that this is a problem on the server side, and the client can't do anything to mitigate it. If the client receives a 201 Created status code, it knows there was no problem with its request, but the resource representation is not in the response's body. For example, if the client receives a 200 OK status code, it knows there was no problem with its request and expects the requested resource representation in the response's body.

This is a general principle that applies to all the HTTP status codes. If there is a problem, what should the client do?.If there is a problem, on which side is it? On the client or on the server side?.

You can fulfill this principle by giving answers to the following questions: The basic principle behind these conventions is that a status code returned in a response must make the client aware of what is going on and what the server expects the client to do next. Although the vast majority of them don't actually implement REST, they usually follow a few RESTful conventions when it comes to HTTP status codes. Most Web APIs are inspired by the REST paradigm. Before going into the specific topic, let's take a quick look at the rationale of HTTP status codes in general.

403 error