Ce qu’il y a derrière l’API
La cuisine dévoilée
Vous vous souvenez de l'analogie du restaurant au chapitre précédent ? Vous êtes assis à une table, vous dites au serveur ce que vous voulez, et le plat arrive. Vous n'entrez jamais dans la cuisine.
Eh bien, il est temps de faire un tour en cuisine.
Quand vous appelez GET /users/1, le serveur ne fait pas apparaître cet utilisateur par magie. Il va le chercher quelque part. Ce "quelque part" est une base de données. Comprendre à quoi ressemble une base de données changera votre vision des API, des fonctionnalités et des discussions avec votre équipe technique.
Une base de données est une collection de tableurs
Voici le secret : une base de données est essentiellement une collection de tableurs. Sérieusement.
Si vous avez déjà utilisé Excel ou Google Sheets, vous comprenez déjà 80 % du fonctionnement des bases de données. Faisons correspondre le vocabulaire :
- Une table est un onglet de votre tableur. Un onglet pour les Utilisateurs, un pour les Commandes, un pour les Produits.
- Une ligne (row) est un enregistrement. Un utilisateur, une commande, un produit.
- Une colonne (column) est un champ. Nom, e-mail, forfait, date de création.
- La colonne ID est comme le numéro de ligne, mais elle ne change jamais, même si vous triez ou supprimez des lignes.
Voici à quoi pourrait ressembler une table Utilisateurs :
| id | nom | forfait | cree_le | |
|---|---|---|---|---|
| 1 | Alice Martin | alice@acme.com | pro | 2024-01-15 |
| 2 | Bob Chen | bob@startup.io | free | 2024-02-20 |
| 3 | Clara Diaz | clara@bigcorp.com | enterprise | 2024-03-08 |
| 4 | David Kim | david@freelance.dev | pro | 2024-04-01 |
Rien de bien effrayant. C'est un tableur avec des lignes et des colonnes. Toutes les applications que vous avez utilisées ont quelque chose de ce genre derrière elles.
La colonne ID est primordiale
Remarquez que chaque ligne possède un id. Ce nombre est l'identifiant unique de chaque enregistrement. Il ne change jamais, et deux lignes ne partagent jamais le même ID.
C'est pour cela que les URL d'API contiennent des ID. Quand vous appelez :
GET /users/2
Vous dites : "Va dans la table Utilisateurs, trouve la ligne où id = 2, et renvoie-la moi."
Le serveur cherche la ligne n°2, récupère les données, les enveloppe dans du JSON et vous les renvoie :
{
"id": 2,
"nom": "Bob Chen",
"email": "bob@startup.io",
"forfait": "free",
"cree_le": "2024-02-20"
}
Regardez le JSON. Regardez le tableau ci-dessus. Ce sont les mêmes données, présentées différemment. La réponse de l'API est la ligne du tableur, convertie en JSON.
CRUD : les quatre actions possibles sur un tableur
Pensez à ce que vous faites réellement dans un tableur. Il n'y a que quatre actions possibles :
- Lire (Read) une ou plusieurs lignes.
- Ajouter (Create) une nouvelle ligne.
- Modifier (Update) une cellule existante.
- Supprimer (Delete) une ligne.
C'est tout. Et ces quatre actions correspondent directement aux méthodes HTTP :
| Action | Tableur | Méthode HTTP | Exemple |
|---|---|---|---|
| Lire | Consulter une ligne | GET | GET /users/2 |
| Créer | Ajouter une ligne | POST | POST /users |
| Modifier | Modifier une cellule | PUT | PUT /users/2 |
| Supprimer | Supprimer une ligne | DELETE | DELETE /users/2 |
Les développeurs appellent cela le CRUD (Create, Read, Update, Delete). Cela sonne technique, mais vous savez déjà ce que cela signifie. C'est ce que vous faites tous les jours dans Excel.
Pourquoi c'est important pour un PM
Quand un ingénieur vous parle de l'API ou du backend, il parle généralement de la base de données. Voici comment traduire :
"Nous ne stockons pas cette donnée." Il n'y a pas de colonne prévue pour cela. Si vous voulez suivre la "date de dernière connexion" mais qu'il n'y a pas de colonne derniere_connexion dans la table Utilisateurs, la donnée n'existe tout simplement pas. Quelqu'un doit ajouter la colonne et écrire le code pour la remplir.
"Ce champ n'existe pas pour l'utilisateur." Même idée. La table Utilisateurs n'a pas de colonne nom_entreprise. Si vous voulez qu'elle apparaisse dans la réponse de l'API, il faut d'abord modifier la base de données.
"Nous devrions ajouter une nouvelle table." La fonctionnalité que vous demandez implique un type de donnée qui ne rentre dans aucun onglet existant. Imaginez demander des "notifications utilisateur" alors qu'il n'y a pas encore d'onglet Notifications.
Ce ne sont pas des excuses. Ce sont de réelles contraintes techniques. Et maintenant, vous pouvez visualiser exactement ce qu'elles impliquent.
Essayez par vous-même
Rendons cela concret. L'endpoint /users de DummyJSON renvoie des données d'une table Utilisateurs. Cliquez sur "Envoyer la requête" pour voir à quoi ressemble un seul utilisateur :
C'est une ligne de la table Utilisateurs, filtrée sur cinq colonnes. Récupérons maintenant plusieurs lignes d'un coup :
Remarquez que la réponse enveloppe les lignes dans un tableau "users". C'est l'API qui vous donne trois lignes de la table, avec seulement les colonnes demandées (select=id,firstName,email).
Chaque API fonctionne ainsi à la base. Un endpoint simple comme /users/1 lit dans une seule table. Des endpoints plus complexes peuvent extraire des données de plusieurs tables à la fois (un endpoint de commande peut combiner des données des tables Commandes, Utilisateurs et Produits). Mais le principe reste le même : le serveur lit des lignes de tables et les renvoie en JSON.
Points clés à retenir
- Une base de données est une collection de tables, comme les onglets d'un tableur.
- Chaque ligne est un enregistrement, chaque colonne est un champ.
- L'ID identifie de manière unique chaque ligne. C'est pourquoi les URL ressemblent à
/users/2. - Le CRUD (Create, Read, Update, Delete) correspond directement à GET, POST, PUT, DELETE.
- Quand les ingénieurs disent "on ne stocke pas ça", ils veulent dire qu'il n'y a pas de colonne pour cette donnée.