codelynx.dev
🇫🇷🇬🇧

Retour • 24/10/2024

Le HTTP comment ça fonctionne ?

Écris par Melvyn Malherbe le 24/10/2024

English version 🇬🇧

Si il y a un truc que tu utiliseras tout le temps dans ta carrière de développeur, c'est les requêtes en réseaux.

Que tu sois sur une application mobile, un site web ou même un un jeu vidéo, il y a presque toujours des requêtes réseaux en HTTP.

Quand j'ai commencé à coder, j'ai trouver ça très compliqué et donc je vais essayer de te l'expliuqer simplement.

HTTP = Protocole

Le HTTP design :

  • Hyper
  • Text
  • Transfer
  • Protocol

Et ce dernier mot, prtocol est très important. Tu peux te demander :

C'est quoi un protocole ?

Un protcole c'est une sorte de convention. Prenons la plus connu au monde : Le facteur.

On est d'accord que quand tu envoie une lettre :

  • le timbre est quelque chose d'arbitraire définit par les humains, mais on sait que si il y a un timbre c'est que tu as payé les frais de l'envoie
  • l'adresse du destinataire écrit sur la même page que le timbre et l'adresse de retours écris sur le verso, c'est encore une fois arbitraire
  • les adresse et leur format sont aussi arbitraire

Finalement, la post c'est un protcole. Pourqoui ? Car un protocole c'est juste des règles que les duex parties connait.

Si toi tu connais les règles de la post et que tu les suis, que tu les donnes à la poste celle-ci sera effactement quoi faire avec ta lettre.

C'est donc un prtocole.

Excalidraw logo

Excalidraw

Le protocole HTTP

De la même manière, HTTP définit pleins de règles. Il y a deux parties :

  1. La requête qui est envoyée par le client
  2. La réponse qui est envoyée par le serveur

Les duex sont tout simplement du texte :

JS
const request = 'Blablabla';
const response = 'Tu dis quoi là ?';

Sauf que ce texte est formatté de manière très précise. Chaque charactères est important.

Une requete et une réponse possède ce qu'on appel un header. La header vient données des informations sur cette requête ou cette réponse.

Voici un exemple de header pour récupérer les utilisateurs de mon serveur, codelynx.dev :

GET /users HTTP/1.1
Host: codelynx.dev
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
Accept: application/json

Ici, il y a plusieurs parties. Dnas la premièr eligne :

  • GET définit la méthode HTTP, GET permet de dire qu'on veut récupérer des données, POST par exemple permet de créer une ressource.
  • /users définit l'adresse de la ressource, ou tout simplement l'URL sur laquel on va récupérer des données.
  • HTTP/1.1 définit le protocole, ici c'est le protocole HTTP version 1.1.

Ensuite, tout ce qui est en dessous c'est la header. C'est une liste de paires de caractères qui définissent les informations sur la requête ou la réponse.

  • Host définit l'adresse du serveur
  • User-Agent définit l'agent utilisateur (les données de ton navigateur etc..)
  • Accept définit le format que tu veux recevoir

Tu peux avoir des centaines de Header.

Ça c'est pour la request, voici à quoi pourrait ressembler la response :

HTTP/1.1 200 OK
Content-Type: application/json

{
  "data": [
    {
      "id": 1,
      "name": "Leanne Graham",
      "email": "Sincere@april.biz",
    }
  ]
}

Boom, cette fois on a une réponse, la première ligne comme avnat vient décirre cette fois :

  • Le protocole HTTP/1.1
  • Le status 200 OK

Le status en gros c'est l'état de la réponse. Il vient nous décrire si la requête à été traité correctement. Ce qu'il faut regarder c'est le premier nombre :

  • 200 = OK
  • 400 = Mauvais requête
  • 500 = Erreur serveur

Il y a pleins de status.

Ensuite il y a encore une fois les headers, ici il y en as qu'une qui nous dit quel est le type de contenu de la réponse :

  • Content-Type: application/json

Et finalement, enfin, il y a la réponse, le contenu, le JSON qui contient l'intégralité des informations que nous voulons.

Tout ça on peut facilement le voir dans le navigatuer :

Les règles HTTP

On va vue que le HTTP n'était que du texte, c'est perturbant. Maintenant ce texte contient plusieurs paramètre qu'on va voir ensemble.

La méthode

Excalidraw logo

Excalidraw

La méthode HTTP définit une action que tu veux faire.

  • GET = Récupérer des données
  • POST = Créer une ressource
  • PUT = Modifier une ressource
  • DELETE = Supprimer une ressource
  • PATCH = Modifier une ressource partiellement

Il faut savoir que ces méthodes sont des bonnes pratiques à suivre, mais ne change rien au résutlat.

Le but de ces méthodes c'est juste de pouvoir, en te rendant sur les mêmes URL, faire des requêtes GET, POST, PUT, DELETE ou PATCH.

Sans elle, il faudrait créer des URL comme :

  • /users/1/delete
  • /users/1/update

Alors qu'on peut juste faire :

  • DELETE : /users/1
  • PUT : /users/1

Ça permet d'avoir une système de "ressources" plus simple à gérer.

Le chemin

L'URL c'est vraiment l'adresse. Par défaut, les sites web fonctionne avec un routing avec des URLs comme :

  • /users
  • /users/1
  • /users/1/update

Etc... la même chose quand tu vas sur Twitter, tu vas te rendre compte que les URL qeu tu as dans ta barre reseemnole à :

  • /home
  • /tweets/32320rdnldsnogs

Tout ça permet de faire un routing, côté bakcend il y a pleins de if (les librairie gère ça normaleemtn) qui font :

JS
if (url.pathnem === '/users') {
  if (url.method === 'GET') {
    // Récupérer tous les utilisateurs
  }
  if (url.method === 'POST') {
    // Créer un utilisateur
  }
}

// ...

Le status

C'est le moyen le plus simple de venir communiquer l'état de la réponse. Il y a pleins de status possibles, mais le plus ipmortant c'est le premier nombre :

  • 100 = Continue
  • 200 = OK
  • 300 = Redirection
  • 400 = Mauvais requête
  • 500 = Erreur serveur

Tu peux le voir comme ça :

Excalidraw logo

Excalidraw

Ces status permettent à ton client, celui qui envoie la request, de savoir quel est l'état de la réponse.

Le body

Finalement le body, comme tout le reste est juste une suite de caractères. POur le comprendre on utilise les Headers qui nous définissent quel est son type.

En fonction de se type, le frontend vient gérer la réponse.

Il faut savoir que généralment, le body est "streamé" c'est pour ça qu'en JavaScritp il faut faire ça avec fetch :

JS
const response = await fetch('https://jsonplaceholder.typicode.com/posts');
const json = await response.json();

Il arrive souvnet que le backend renvoie la réponse avant que le le body soit complet.

En faisant await response.json() on dit au frontend de "attendre que le body soit complet".

Les headers

Les headers sont des informations qui sont envoyées par le serveur. Ils sont utilisés pour décrire le contenu de la réponse.

Voici quelques headers que tu peux rencontrer :

  • Content-Type = Le type de contenu de la réponse
  • Content-Length = La taille du contenu de la réponse
  • Content-Encoding = Le type d'encodage du contenu de la réponse
  • Content-Disposition = Le type de disposition du contenu de la réponse
  • Content-Language = La langue du contenu de la réponse
  • une infinité d'autre

Il faut savoir que tu peux être capable de communiquer n'importe quel information via les headers.

Fetch

Maintenant que tu comprends les bases du protocole HTTP, voyons comment utiliser ces connaissances pour effectuer une requête fetch en JavaScript. Fetch est une API moderne qui te permet de faire des requêtes HTTP de manière simple et efficace.

Exemple de requête fetch

Pour faire une requête fetch, tu vas utiliser la méthode fetch() qui est native dans les navigateurs modernes. Voici un exemple de comment tu pourrais récupérer des données d'une API :

JAVASCRIPT
const fetchData = async () => {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'GET', // La méthode HTTP
      headers: {
        Accept: 'application/json', // Le type de contenu que tu veux recevoir
        'Content-Type': 'application/json', // Le type de contenu que tu envoies
      },
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const data = await response.json(); // Convertir la réponse en JSON
    console.log(data); // Afficher les données dans la console
  } catch (error) {
    console.error('Erreur lors de la récupération des données:', error);
  }
};

fetchData();

Décomposition de la requête

  1. URL: C'est l'adresse de l'API que tu veux interroger. Dans cet exemple, c'est https://jsonplaceholder.typicode.com/posts.

  2. Méthode: La méthode HTTP que tu utilises. Ici, c'est GET car tu veux récupérer des données.

  3. Headers: Ce sont des informations supplémentaires que tu envoies avec ta requête. Dans cet exemple, tu spécifies que tu acceptes du JSON et que tu envoies du JSON.

  4. Gestion des erreurs: Utiliser response.ok pour vérifier si la requête a réussi. Si ce n'est pas le cas, tu lances une erreur avec le statut HTTP.

  5. Conversion de la réponse: Utiliser await response.json() pour convertir la réponse en un objet JavaScript.

Pourquoi utiliser fetch ?

Fetch est asynchrone et utilise des Promises, ce qui te permet de gérer les requêtes de manière non bloquante. Cela signifie que ton application peut continuer à fonctionner pendant que la requête est en cours, ce qui est essentiel pour une bonne expérience utilisateur.

En utilisant fetch, tu peux facilement interagir avec des APIs et récupérer des données pour les afficher dans ton application. C'est un outil puissant pour tout développeur web.

Tu peux savoir plus sur fetch en jetant un oeil sur mon article ! Tu pourrais aussi vouloir comprendre la roadmap pour devenir développeur web pour t'aider dans ton apprentissage.

D'ailleurs moi j'ai une formation gratuite pour toi, c'est BeginWeb pour bien commencer :

Deviens développeur web

Profite d'une formation HTML / CSS / JS pour devenir développeur web rapidement.

Reçois la formation gratuitement dans ta boîte mail :

BeginWeb

Cours HTML / CSS / JS gratuit

Maîtrise le web rapidement avec cette formation.