Opérations CRUD : Create, Read, Update, Delete expliqué

Qu'est-ce que CRUD ?

CRUD est l'acronyme de Create, Read, Update, Delete (créer, lire, mettre à jour, supprimer), les quatre opérations de base sur des données stockées. Une base de données les exécute sous forme d'instructions SQL, une API REST les expose comme méthodes HTTP, et la plupart des écrans d'administration s'articulent autour d'elles. Si une fonctionnalité se décrit avec l'un de ces quatre verbes, c'est du CRUD.

Correspondance entre CRUD, SQL et HTTP

Exemple de CRUD : une table users

Les mêmes quatre opérations en SQL :

-- Create
INSERT INTO users (email, name) VALUES ('alice@example.com', 'Alice');
-- Read
SELECT * FROM users WHERE id = 42;
-- Update
UPDATE users SET name = 'Alice Smith' WHERE id = 42;
-- Delete
DELETE FROM users WHERE id = 42;

Et sous forme d'appels à une API REST, où chaque appel cible un endpoint d'API :

POST   /users        {"email": "alice@example.com", "name": "Alice"}   -> 201 Created, Location: /users/42
GET    /users/42                                                      -> 200 OK
GET    /users?limit=20&offset=0                                       -> 200 OK (a page of users)
PUT    /users/42     {"email": "alice@example.com", "name": "Alice Smith"} -> 200 OK (full replace)
PATCH  /users/42     {"name": "Alice Smith"}                          -> 200 OK (partial change)
DELETE /users/42                                                      -> 204 No Content

PUT ou PATCH

Un PUT remplace la ressource entière : l'appelant envoie donc le nouvel état complet. Un PATCH décrit seulement la modification d'une partie : on n'envoie que les champs modifiés. Utilisez PATCH pour les formulaires d'édition courants et PUT quand le client détient réellement l'enregistrement complet.

Quelles méthodes peut-on rejouer sans risque ?

D'après MDN, GET, PUT et DELETE sont idempotentes : répéter la requête laisse le serveur dans le même état. Pour POST et PATCH, ce n'est pas garanti, et un Create rejoué peut donc créer un doublon. Les clés d'idempotence règlent le problème, voir idempotence et la sémantique HTTP dans la RFC 9110.

CRUD au-delà de REST

GraphQL n'a pas d'endpoint par verbe : les lectures sont des queries et les écritures des mutations. gRPC nomme ses méthodes d'après l'opération (CreateUser, GetUser). Les systèmes à base d'événements enregistrent des événements comme UserCreated au lieu d'écraser des lignes. Détails dans l'entrée GraphQL.

mutation { createUser(input: {...}) { id } }
query    { user(id: 42) { id name } }
mutation { updateUser(id: 42, input: {...}) { id } }
mutation { deleteUser(id: 42) { success } }

Erreurs fréquentes en CRUD

• Listes sans pagination. Un endpoint qui renvoie toutes les lignes ralentit puis finit par échouer quand la table grossit. Voir la pagination d'API.
• Requêtes N+1. La liste lance une requête supplémentaire par enregistrement. Utilisez des jointures ou un chargement anticipé.
• Mises à jour perdues. Deux clients modifient le même enregistrement et la dernière écriture l'emporte. Utilisez un ETag ou un champ de version.
• PUT avec un corps partiel. Le serveur remplace l'enregistrement et vide les champs que l'appelant a omis.
• 200 avec un corps vide pour un enregistrement absent. Renvoyez 404.
• Suppressions en cascade silencieuses. Supprimer un utilisateur supprime aussi ses commandes.
• SQL construit à partir de saisies utilisateur. Utilisez toujours des requêtes paramétrées.
• Autorisation uniquement sur les écritures. Les lectures exposent aussi des données.

Tester et surveiller une API CRUD

Une API CRUD cède en général aux mêmes endroits sous charge : listes lentes, verrous sur les mises à jour et créations en double lors des nouvelles tentatives. Scriptez un parcours complet créer, lire, modifier, supprimer et lancez-le avec les tests de charge LoadFocus, qui exécutent des scripts JMeter et k6 depuis 25 régions cloud. Après la mise en production, la surveillance d'API peut tester vos endpoints de lecture (les contrôles gratuits s'exécutent toutes les 5 minutes) et vérifier le code de statut et le corps de la réponse. Pour aller plus loin : comment tester la charge d'API RESTful et tests d'API.

Questions fréquentes : opérations CRUD

Toutes les API sont-elles du CRUD ?

Beaucoup d'API de données s'y prêtent bien. Celles qui portent de la logique métier utilisent souvent d'autres verbes, par exemple POST /transfers ou POST /users/42/send-welcome-email.

Quelle différence entre CRUD et REST ?

CRUD désigne les quatre opérations. REST est un style d'architecture d'API qui associe souvent, mais pas toujours, ces opérations aux méthodes HTTP.

Faut-il une suppression logique ou physique ?

La suppression logique (un horodatage deleted_at) conserve l'historique et reste réversible. La suppression physique est nécessaire pour effacer des données pour des raisons légales ou libérer de l'espace.

Comment éviter les mises à jour perdues ?

Avec la concurrence optimiste : le client envoie l'ETag ou la version qu'il a lue, et le serveur refuse l'écriture si l'enregistrement a changé entre-temps.

Chaque modèle a-t-il besoin des quatre opérations ?

Non. Des ressources en lecture seule ou en ajout seul conviennent très bien. N'exposez que les opérations dont votre cas d'usage a besoin.