Les réponses HTTP constituent une partie importante de la communication web, permettant aux serveurs de répondre aux requêtes des clients avec les données demandées, les informations de statut et d'autres détails clés. Cet article expliquera la structure et les parties d'une réponse HTTP, y compris la ligne de statut, les en-têtes et le corps. Nous examinerons les différents groupes de codes de statut HTTP et leur signification, avec des exemples concrets pour montrer comment ils sont utilisés. Nous aborderons également les bonnes pratiques pour gérer les réponses HTTP dans le développement web, côté client et côté serveur, afin d'assurer une bonne communication entre clients et serveurs.
Points clés
- Une réponse HTTP est le message qu'un serveur web renvoie à un client après avoir reçu et traité une requête HTTP.
- Les composants clés d'une réponse HTTP incluent la ligne de statut, les en-têtes et un corps optionnel contenant le contenu demandé.
- Les codes de statut HTTP sont catégorisés en réponses informatives (1xx), réponses réussies (2xx), messages de redirection (3xx), réponses d'erreur client (4xx) et réponses d'erreur serveur (5xx).
- Côté client, il est important de vérifier les codes de statut, traiter les données de réponse en fonction de l'en-tête Content-Type, et gérer les redirections et erreurs de manière appropriée.
- Côté serveur, définir les codes de statut et en-têtes corrects, fournir des messages d'erreur clairs, et mettre en œuvre une gestion des erreurs et une journalisation appropriées sont indispensables pour un développement web efficace.
Qu'est-ce qu'une réponse HTTP ?
Une réponse HTTP est le message qu'un serveur web renvoie à un client après avoir reçu et traité une requête HTTP. Elle délivre le résultat de la requête du client, que ce résultat soit un succès, un échec ou quelque chose entre les deux. La réponse inclut des informations de statut sur la requête et peut également contenir du contenu dans son corps, comme la ressource demandée (une page web, une image, des données JSON, etc.), ou un message d'erreur.
Les réponses HTTP sont nécessaires pour qu'un client comprenne si sa requête a réussi ou non et quel a été le résultat de cette requête. Les navigateurs web utilisent les réponses HTTP pour savoir quel contenu afficher aux utilisateurs. Les API utilisent les réponses HTTP pour indiquer le résultat des opérations et renvoyer des données. La structure et le contenu de la réponse HTTP déterminent comment le client procède.
Composants d'une réponse HTTP
Une réponse HTTP se compose de plusieurs éléments clés :
- Ligne de statut : La première ligne de la réponse, qui inclut la version HTTP, un code de statut et un message de statut.
- En-têtes : Des paires clé-valeur qui fournissent des informations supplémentaires sur la réponse, comme le type de contenu, la longueur du contenu, les directives de cache, etc.
- Corps (optionnel) : Le contenu réel de la réponse, comme du HTML, du JSON, une image, etc.
Voici un exemple d'une réponse HTTP simple :
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>Page d'exemple</title>
</head>
<body>
<h1>Bonjour le monde !</h1>
<p>Ceci est une page d'exemple.</p>
</body>
</html>
Exemples concrets
Navigation web : Lorsque vous entrez une URL dans votre navigateur web, celui-ci envoie une requête HTTP au serveur. Le serveur répond ensuite avec une réponse HTTP qui inclut le contenu HTML de la page web. Votre navigateur utilise cette réponse pour afficher la page.
Interaction avec une API : Lorsqu'une application fait une requête à un endpoint d'API, le serveur API répond avec une réponse HTTP. Cette réponse inclut souvent des données JSON que l'application peut utiliser. Par exemple, une application météo peut faire une requête à une API météo et recevoir les données météorologiques actuelles dans la réponse.
Téléchargement de fichier : Lorsque vous cliquez sur un lien pour télécharger un fichier, votre navigateur envoie une requête HTTP au serveur. Le serveur répond avec une réponse HTTP qui inclut les données du fichier dans le corps et des en-têtes qui indiquent le type et la taille du fichier.
Composants d'une réponse HTTP
Une réponse HTTP comporte plusieurs parties clés qui fournissent des informations sur le résultat de la requête et délivrent les données demandées.
Ligne de statut
La ligne de statut est la première ligne de la réponse HTTP. Elle inclut :
- Version HTTP : Indique la version du protocole HTTP utilisée, comme HTTP/1.1 ou HTTP/2.
- Code de statut : Un nombre à trois chiffres qui indique le résultat de la requête, comme 200 pour un succès, 404 pour « non trouvé », ou 500 pour une erreur serveur.
- Texte de statut : Une brève description du code de statut, comme « OK » pour 200, « Not Found » pour 404, ou « Internal Server Error » pour 500.
Voici quelques codes de statut HTTP courants et leur signification :
| Code de statut | Texte de statut | Signification |
|---|---|---|
| 200 | OK | La requête a réussi et le corps de la réponse contient les données. |
| 201 | Created | La requête a réussi et une nouvelle ressource a été créée. |
| 301 | Moved Permanently | La ressource demandée a été déplacée de façon permanente vers une nouvelle URL. |
| 400 | Bad Request | Le serveur n'a pas pu comprendre la requête en raison d'une syntaxe invalide. |
| 401 | Unauthorized | La requête nécessite une authentification de l'utilisateur. |
| 404 | Not Found | Le serveur n'a pas pu trouver la ressource demandée. |
| 500 | Internal Server Error | Le serveur a rencontré une erreur inattendue. |
Le code de statut HTTP fait partie du message de réponse. Il définit la classe de réponse et joue un rôle de catégorisation. Le premier chiffre du code de statut indique le type de réponse :
- 1xx : Réponse informative
- 2xx : Succès
- 3xx : Redirection
- 4xx : Erreur client
- 5xx : Erreur serveur
Les codes de statut HTTP sont extensibles, mais les applications HTTP ne sont pas tenues de comprendre la signification de tous les codes de statut enregistrés. Des informations supplémentaires sur la réponse peuvent être trouvées dans les champs d'en-tête de réponse.
En-têtes de réponse
Après la ligne de statut viennent les en-têtes de réponse. Ce sont des paires clé-valeur qui donnent plus de détails sur la réponse. Quelques en-têtes courants incluent :
- Server : Le type de serveur qui a généré la réponse, comme « Apache/2.4.41 (Ubuntu) ».
- Content-Type : Le type MIME des données dans le corps de la réponse, comme « text/html » pour du HTML ou « application/json » pour du JSON.
- Content-Length : La taille du corps de la réponse en octets.
- Cache-Control : Instructions pour les mécanismes de cache, spécifiant si la réponse peut être mise en cache, pendant combien de temps, etc. Par exemple, « max-age=3600 » signifie que la réponse peut être mise en cache pendant une heure.
- Set-Cookie : Envoie des cookies du serveur au client, comme « session_id=abc123; Expires=Wed, 21 Jun 2023 07:28:00 GMT ».
Ligne vide
Après les en-têtes, il y a une ligne vide. Cette ligne vide signale la fin de la section des en-têtes de la réponse.
Corps de la réponse
Après la ligne vide se trouve le corps de la réponse. Celui-ci contient les données réelles qui ont été demandées, comme :
Un fichier HTML pour une page web :
<!DOCTYPE html> <html> <head> <title>Page d'exemple</title> </head> <body> <h1>Bienvenue sur la page d'exemple</h1> <p>Ceci est un exemple de corps de réponse HTML.</p> </body> </html>Des données JSON pour une réponse d'API :
{ "name": "John Doe", "age": 30, "city": "New York" }Une image, une vidéo ou un autre fichier média.
Un fichier à télécharger, comme un PDF ou une archive ZIP.
Si la réponse indique une erreur, comme un code de statut 404 ou 500, le corps peut contenir un message d'erreur fournissant plus de détails sur le problème, comme :
<!DOCTYPE html>
<html>
<head>
<title>404 Non trouvé</title>
</head>
<body>
<h1>404 Non trouvé</h1>
<p>La ressource demandée n'a pas pu être trouvée sur ce serveur.</p>
</body>
</html>
Le corps de la réponse est optionnel. Pour certaines requêtes, comme une requête HEAD ou une réponse 204 « No Content », il n'y aura pas de corps.
Catégories de codes de statut de réponse HTTP
Les codes de statut de réponse HTTP sont divisés en cinq catégories selon leur premier chiffre. Chaque catégorie représente une classe différente de réponses.
Réponses informatives (100-199)
Les codes de statut dans la plage 100-199 signifient que le serveur a reçu la requête et est en train de la traiter. Ce sont des réponses. Quelques codes de statut informatifs courants incluent :
| Code de statut | Description |
|---|---|
100 Continue |
Le serveur a reçu les en-têtes de la requête et le client doit envoyer le corps de la requête. |
102 Processing |
Le serveur a reçu et traite la requête, mais aucune réponse n'est encore disponible. |
Exemple de scénario :
- Un client envoie une requête POST avec une charge utilevolumineuse. Le serveur répond avec un code de statut
100 Continuepour indiquer au client d'envoyer le corps de la requête.
Réponses réussies (200-299)
Les codes de statut dans la plage 200-299 signifient que le serveur a reçu, compris et accepté la requête. Quelques codes de statut de succès courants incluent :
| Code de statut | Description |
|---|---|
200 OK |
La requête a réussi et le corps de la réponse contient les données demandées. |
201 Created |
La requête a réussi et une nouvelle ressource a été créée. Ceci est couramment utilisé comme réponse à une requête POST. |
204 No Content |
Le serveur a satisfait la requête mais n'a pas besoin de retourner de contenu. |
Exemples de scénarios :
- Un client demande une page web en utilisant une requête GET. Le serveur répond avec un code de statut
200 OKet retourne le contenu HTML. - Un client soumet un formulaire pour créer une nouvelle ressource en utilisant une requête POST. Le serveur crée la ressource et répond avec un code de statut
201 Created. - Un client envoie une requête DELETE pour supprimer une ressource. Le serveur supprime la ressource et répond avec un code de statut
204 No Content.
Messages de redirection (300-399)
Les codes de statut dans la plage 300-399 signifient que le client doit effectuer une action supplémentaire pour compléter la requête. L'action peut être effectuée par l'agent utilisateur sans interaction avec l'utilisateur. Quelques codes de statut de redirection courants incluent :
| Code de statut | Description |
|---|---|
301 Moved Permanently |
La ressource demandée s'est vue attribuer un nouvel URI permanent et les références futures devraient utiliser l'un des URI retournés. |
302 Found |
La ressource demandée se trouve sous un URI différent. Le client doit continuer à utiliser l'URI de requête pour les requêtes futures. |
304 Not Modified |
La ressource n'a pas été modifiée depuis la version spécifiée par les en-têtes de la requête, donc le client peut continuer à utiliser la version en cache. |
Exemples de scénarios :
- Un client demande une ressource qui a été déplacée de façon permanente vers une nouvelle URL. Le serveur répond avec un code de statut
301 Moved Permanentlyet inclut la nouvelle URL dans l'en-têteLocation. - Un client demande une ressource qui se trouve sous une URL différente. Le serveur répond avec un code de statut
302 Foundet inclut l'URL temporaire dans l'en-têteLocation. - Un client envoie une requête GET conditionnelle avec l'en-tête
If-Modified-Since. Si la ressource n'a pas été modifiée depuis la date spécifiée, le serveur répond avec un code de statut304 Not Modified.
Réponses d'erreur client (400-499)
Les codes de statut dans la plage 400-499 signifient que le client semble avoir commis une erreur. Sauf lors d'une réponse à une requête HEAD, le serveur devrait inclure une entité expliquant l'erreur. Quelques codes de statut d'erreur client courants incluent :
| Code de statut | Description |
|---|---|
400 Bad Request |
Le serveur n'a pas pu comprendre la requête en raison d'une syntaxe incorrecte. |
401 Unauthorized |
La requête nécessite une authentification de l'utilisateur. |
404 Not Found |
Le serveur n'a rien trouvé correspondant à l'URI de requête. |
Exemples de scénarios :
- Un client envoie une requête avec des paramètres invalides ou manquants. Le serveur répond avec un code de statut
400 Bad Requestet inclut un message d'erreur dans le corps de la réponse. - Un client tente d'accéder à une ressource protégée sans fournir d'authentification valide. Le serveur répond avec un code de statut
401 Unauthorizedet invite le client à s'authentifier. - Un client demande une ressource qui n'existe pas sur le serveur. Le serveur répond avec un code de statut
404 Not Found.
Réponses d'erreur serveur (500-599)
Les codes de statut dans la plage 500-599 signifient que le serveur sait qu'il a commis une erreur ou qu'il est incapable d'exécuter la requête. Sauf lors d'une réponse à une requête HEAD, le serveur devrait inclure une entité expliquant l'erreur, et si c'est une condition temporaire ou permanente. Quelques codes de statut d'erreur serveur courants incluent :
| Code de statut | Description |
|---|---|
500 Internal Server Error |
Le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la requête. |
503 Service Unavailable |
Le serveur est actuellement incapable de gérer la requête en raison d'une surcharge temporaire ou d'une maintenance du serveur. |
504 Gateway Timeout |
Le serveur, agissant comme passerelle ou proxy, n'a pas reçu de réponse dans les temps du serveur en amont auquel il devait accéder pour compléter la requête. |
Exemples de scénarios :
- Un client demande une ressource, mais une erreur inattendue se produit côté serveur. Le serveur répond avec un code de statut
500 Internal Server Erroret enregistre l'erreur pour investigation. - Un client tente d'accéder à un service qui est temporairement hors service pour maintenance. Le serveur répond avec un code de statut
503 Service Unavailableet peut inclure un en-têteRetry-Afterpour indiquer quand le service devrait être à nouveau disponible. - Un client demande une ressource qui nécessite que le serveur communique avec un serveur en amont. Si le serveur en amont met trop de temps à répondre, le serveur envoie un code de statut
504 Gateway Timeoutau client.
Pour plus d'informations sur les codes de statut HTTP, vous pouvez consulter les ressources suivantes :
Gestion des réponses HTTP dans le développement web
Lors de la création d'applications web, vous devez gérer correctement les réponses HTTP côté client et côté serveur. Cela contribue à créer une bonne expérience utilisateur et aide au débogage et à la maintenance de l'application.
Côté client
Côté client, comme dans un navigateur web ou une application mobile, vous devez :
Vérifier les codes de statut : Après l'envoi d'une requête HTTP, le client doit vérifier le code de statut HTTP de la réponse pour voir si la requête a fonctionné ou non. Par exemple :
Code de statut Signification 200 OK Succès 404 Ressource demandée non trouvée Traiter les données de réponse : En fonction du code de statut et du champ d'en-tête
Content-Type, le client doit traiter le corps de la réponse de la bonne manière. Par exemple :Content-Type Action HTML Le navigateur l'affichera JSON Analyser en objet pour utilisation ultérieure Gérer les redirections et erreurs : Si le code de statut signifie une redirection (codes 3xx), le client doit suivre la nouvelle URL dans l'en-tête
Location. Pour les codes d'erreur client (4xx) et d'erreur serveur (5xx), le client doit afficher des messages d'erreur à l'utilisateur et peut-être réessayer la requête ou demander à l'utilisateur de faire quelque chose.
Exemple de gestion d'un message de réponse HTTP en JavaScript utilisant l'API Fetch :
fetch('https://api.example.com/data')
.then(response => {
if (!response.ok) {
throw new Error(`Erreur HTTP ! statut : ${response.status}`);
}
return response.json();
})
.then(data => {
console.log(data);
// Traiter les données
})
.catch(error => {
console.error('Erreur :', error);
// Gérer l'erreur
});
Côté serveur
Côté serveur, vous devez :
Définir les bons codes de statut et en-têtes : Lors de l'envoi d'une réponse, le serveur web doit définir le bon code de statut HTTP pour indiquer le résultat du traitement de la requête. Il doit également inclure des champs d'en-tête de réponse, comme
Content-Type, pour aider le client à comprendre correctement la réponse.Fournir des messages d'erreur clairs : Pour les réponses d'erreur client et serveur, le serveur doit inclure un message d'erreur clair et concis dans le corps de la réponse. Cela aide les développeurs à comprendre ce qui s'est mal passé et comment le corriger.
Mettre en œuvre une bonne gestion des erreurs et journalisation : Côté serveur, il est important d'intercepter et de gérer les erreurs correctement. Cela signifie enregistrer les erreurs pour analyse et débogage ultérieurs, et ne pas exposer de données sensibles dans les messages d'erreur envoyés au client.
Exemple d'envoi d'une réponse HTTP en Node.js utilisant Express :
app.get('/data', (req, res) => {
try {
const data = getDataFromDatabase();
res.status(200).json(data);
} catch (error) {
console.error('Erreur :', error);
res.status(500).json({ error: 'Erreur interne du serveur' });
}
});
