We mentioned HTTP in the chapter discussing
communication protocols.
We used it as an example because it is one of the most widespread and well-known protocols.
It is used in the communication between web clients and web servers.
Web clients, such as Chrome or Firefox, communicate with machines (servers) to retrieve data from the web, like a website's content or other resources.
The HTTP protocol has defined codes that are returned in every server response to a client.
These codes help the client better handle the response and understand its content.
You've likely encountered a website that directly displays some of these codes on a page, especially in case of an error, such as the famous "404, page not found."
To see more, open your browser console (F12 in Chrome) and go to the network tab. By clicking on a line, you'll see details of the requests and their responses.
These codes are numbers between 100 and 599, divided into five categories:
- 1xx: Informational, the request has been received and is being processed.
- 2xx: Success.
- 3xx: Redirection, additional action is required to complete the request.
- 4xx: Client-side error.
- 5xx: Server-side error.
There are currently 75 HTTP codes, about fifteen of which are commonly used by developers:
- 200: OK. The request was successful.
- 201: Created. A resource was successfully created, for instance, creating a user.
- 202: Accepted. The request has been accepted but is not yet processed. The server informs the client: "I’ve received your request, I’ll process it later, you can go back to your tasks."
- 204: No Content. The request was successful, but there is no content to return. Often used for updates or deletions.
- 301: Moved Permanently. The resource has been permanently moved. This is essential when changing a site's URLs to redirect existing links to the new page. It ensures users aren’t lost and search engines understand the change and retain the page’s SEO value.
- 304: Not Modified. Commonly used to inform the client that the content it already knows is still up-to-date, avoiding unnecessary data transmission and network congestion.
- 400: Bad Request. The request is invalid. It’s poorly formatted, missing a field, has a value of the wrong type, etc.
- 401: Unauthorized. The user is not authenticated. For example, trying to use the "add to favorites" feature without being logged in.
- 403: Forbidden. The user is not authorized to perform this action. For example, accessing a page reserved for administrators.
- 404: Not Found. The resource does not exist.
- 405: Method Not Allowed. Attempting to perform an unsupported operation on a resource. For example, trying to modify customer account details when the developer only implemented account creation from scratch.
- 409: Conflict. Used when a request doesn’t make sense in a business context. For instance, requesting account creation with an already-used email.
-
429: Too Many Requests. Protections are in place to prevent overwhelming production infrastructure.
This is especially helpful against Distributed Denial of Service (DDoS) attacks, where malicious actors use devices like baby monitors to send millions of requests to your site.
It's also useful for handling unexpected traffic surges during special events. For example, at L'Équipe, this might be returned during an exceptional PSG match night. - 500: Internal Server Error. A server-side error, often due to a bug or unexpected issue.
- 502: Bad Gateway. In large, high-traffic setups, web browsers don’t directly send requests to the servers executing business logic. The request first goes through a proxy managing cache and security. A 502 is returned if the proxy itself encounters an error from the protected server.
- 503: Service Unavailable. The server is temporarily unavailable, likely due to maintenance.
- And the most important code of all: 418, "I’m a teapot." It was introduced in 1998 as an April Fool's joke as part of the "Hyper Text Coffee Pot Control Protocol" specification. This is the code to return when a teapot is asked to brew coffee. Today, it remains as an Easter egg in some software.
So far, every time I’ve mentioned HTTP clients, I’ve talked about the most well-known ones: web browsers.
They enable exchanges on the Web between users and a server through a graphical interface.
In the backend,
we often build architectures divided into smaller pieces. These components, usually, also communicate via HTTP, so there’s a client here as well.
Developers use specialized clients designed solely to send requests and receive responses. These are directly passed on to the rest of the software without interpretation.
That’s why HTTP codes are crucial for developers. They help us better understand the response content, so we can decide what to do with it: transform it, analyze it, cache it, reject it, resend a request...