Understand HTTP 4xx Client Error Response Codes
The 4xx family of status codes are used in HTTP responses to inform the client/browser of an error relating to the user’s request. The status codes in this family are intended to indicate a problem that should be possible to fix or remedy by the user or developer. For example, a 401 Unauthorized status code lets the user/developer know they need to provide authorization information with their request; should they re-submit the request with the additional authorization header, the request may succeed. We will explore the available client error status codes, and what additional information they convey.
[00:00] The 400 family of HTTP response status codes are used to indicate client errors. Normally, this means these are errors that can be resolved by some change in the client in the way it is making its request. For instance, fixing the URL in the request or perhaps specifying a different accept header.
[00:20] The most common 400 family status code is the 404 status code, used to indicate "Not found." Making a request to a GitHub user that does not actually exist on the GitHub API, we can see that the GitHub server has responded with a 404 Not Found. The user that we're looking for is not available, does not exist on the system.
[00:40] Of course, the resolution would be to fix our request and use a URL of an actual existing user in order to get a different status code back. Another more generic status code we can receive is a 400 Bad request status code. We'll make the request to create a GitHub issue, but instead of using JSON as expected we will try and use a form url-encoded request.
[01:04] We can see that the GitHub server has responded with a 400 Bad Request response, it does not understand how to parse or receive our form-encoded request to create an issue. It's expecting JSON. In order to fix this, we should change our request to use JSON-encoded body instead for form-urlencoded.
[01:22] It's nothing the server is responsible for fixing. Similarly, a 422 Unprocessable Entity code might be used if you send the correct type of request but what's included does not include all of the necessary fields for instance. Again, here we will make a request to create a GitHub issue and format it as JSON this time, but we will not include a required field, the title field.
[01:48] We can see that the GitHub API has responded with a 422 status code. The other common use for the 400 family of status codes is to indicate authorization or authentication problems. Here I'll make a request to the GitHub API for our current user, but we will not authenticate our request.
[02:04] The GitHub API has returned a 401 Unauthorized status code. We have not sent any authentication information and we can not make a request to this until we have authenticated ourselves. Similarly, the 403 Forbidden status code can be used to indicate a request that can't be made, that the server will not allow for some reason.
[02:26] Sometimes this can be because as a user you don't have permission to perform that specific operation, or there is some other forbidden use of the API. Here we can see, GitHub has indicated that the user agent is a required request header so they can identify the agents that are used to consume their API.
[02:45] To summarize, the 400 family HTTP response status codes are used to indicate client errors -- things that normally can be resolved by adjusting or changing the request made by the client in order to have a correct response.
Thank you everyone for the comments informing us of the encoding issues. Properly encoded versions of the affected lessons have been uploaded, and should be working correctly know.
Thanks again!