Les verbes qui actionnent la machine
Chaque requête HTTP porte un verbe. Une intention.
Ces méthodes ne sont pas de simples commandes — elles ont une sémantique.
Un contrat tacite entre client et serveur.
Les respecter, c’est garantir que tout le monde parle le même langage, même dans le noir.
GET : lecture
La méthode la plus courante, la plus propre.
GET /clients/52
Elle demande une représentation de la ressource.
Rien ne change côté serveur. Aucun effet secondaire.
C’est une consultation, pas une action.
Safe et idempotent. On peut l’appeler cent fois, le résultat sera le même.
POST : création
La méthode floue, la plus flexible.
POST /clients
Sert à créer une nouvelle ressource dont on ne connaît pas l’identifiant à l’avance.
Ou à déclencher un traitement qui ne correspond pas aux autres verbes.
Chaque appel génère généralement quelque chose de nouveau — une facture, un utilisateur, un ticket.
Ni safe, ni idempotente : deux appels identiques créent deux ressources.
PUT : remplacement
La méthode qui remplace intégralement.
PUT /clients/52
Le client envoie une représentation complète. Le serveur l’applique.
Si la ressource n’existe pas, il peut la créer (selon l’API).
L’identifiant est connu à l’avance, imposé par le client.
Idempotent : l’appeler une fois ou dix donne le même état final.
Mais pas safe — ça modifie.
PATCH : modification partielle
La méthode chirurgicale.
PATCH /clients/52
Le client n’envoie que les champs à mettre à jour.
Le format de la modification doit être standardisé (JSON Patch, JSON Merge Patch).
Moins lourd que PUT, plus précis.
Idempotent si bien conçu, mais pas safe.
DELETE : suppression
La méthode définitive.
DELETE /clients/52
Demande la suppression de la ressource identifiée.
Après un DELETE réussi, un GET sur la même URI renvoie généralement 404.
Idempotent : supprimer plusieurs fois ne change rien après la première fois.
Pas safe, évidemment.
Concepts importants
Méthodes safe
Les méthodes qui ne modifient pas l’état du serveur.
GET, HEAD, OPTIONS.
On peut les appeler sans craindre de laisser une trace, un effet.
Comme lire un dossier sans y toucher.
Méthodes idempotentes
Les méthodes dont l’effet est le même, qu’on les appelle une ou plusieurs fois.
GET, PUT, DELETE.
POST n’est pas idempotente — chaque appel peut créer une nouvelle ressource.
L’idempotence est cruciale pour la fiabilité : en cas d’échec réseau, on peut rejouer la requête sans danger.
Ces méthodes structurent le dialogue.
Elles donnent un sens à chaque appel, une promesse sur ce qui va se passer.
Dans une API REST bien conçue, il suffit de regarder l’URI et le verbe pour comprendre l’intention.
Pas besoin de manuel. Juste du respect pour la sémantique.