CRUD et REST, quelle différence ?

Arfan Sharif - mai 4, 2023

REpresentational State Transfer — ou REST — est un style d’architecture logicielle permettant de créer des API qui communiquent à l’aide du protocole HTTP.

Dans le cadre de leurs opérations, les API ont souvent besoin de manipuler des données en arrière-plan. Ces opérations essentielles liées aux données, généralement exécutées sur des bases de données backend, sont désignées par l’acronyme CRUD, à savoir Create (Créer), Read (Lire), Update (Mettre à jour) et Delete (Supprimer).

Dans la mesure où les API REST exécutent des opérations CRUD, il est important que les développeurs d’API et les ingénieurs en données comprennent la relation entre ces deux concepts. En effet, bien qu’ayant des objectifs différents, ces concepts peuvent avoir un impact négatif sur leurs performances respectives.

Dans cet article, nous vous présenterons les concepts CRUD et REST, leurs similitudes et leurs différences, et vous expliquerons ensuite comment optimiser la surveillance de leurs performances.

CRUD : de quoi s’agit-il ?

Les opérations CRUD sont liées aux systèmes traditionnels de gestion des bases de données relationnelles (tels que PostgreSQL ou SQL Server) et aux bases de données NoSQL plus récentes (comme MongoDB ou DynamoDB). Bien que les opérations axées sur les fichiers manipulent également des informations, le CRUD fait généralement référence aux opérations axées sur les enregistrements dans des bases de données informatiques.

Dans les systèmes de gestion de bases de données relationnelle (RDBMS), une ligne de table de base de données correspond à un enregistrement, tandis que les colonnes sont appelées des attributs ou des champs. Passons en revue les quatre opérations CRUD.

Create

L’opération Create ajoute un nouvel enregistrement à une base de données. L’équivalent SQL de cette opération est INSERT.

Read

L’opération Read récupère des enregistrements (ou encore des documents ou des éléments, selon le type de base de données) à partir d’une table de base de données (ou d’une collection) en fonction de certains critères de recherche. L’équivalent SQL de cette opération est SELECT. Les opérations Read peuvent renvoyer un sous-ensemble d’enregistrements et de champs, selon la requête.

Update

L’opération Update (également UPDATE dans SQL) modifie des enregistrements existants dans une base de données. Tout comme l’opération Read, l’opération Update affecte tout ou partie des enregistrements et/ou des champs.

Delete

L’opération Delete (également DELETE dans SQL) supprime un ou plusieurs enregistrements de la base de données.

Dans les bases de données NoSQL, les expressions qui correspondent à des opérations CRUD dépendent de la plateforme, de la structure des données et du langage. Par exemple, dans MongoDB :

  • L’opération Create utilise db.collection.insertOne() ou db.collection.insertMany().
  • L’opération Read utilise db.collection.find() ou db.collection.findOne().
  • L’opération Update utilise db.collection.updateOne(), db.collection.updateMany() ou db.collection.replaceOne().
  • L’opération Delete utilise db.collection.deleteOne() ou db.collection.deleteMany().

En général, le code d’application de l’API exécute les opérations CRUD en invoquant des procédures, des fonctions ou des déclencheurs stockés dans les systèmes RDBMS. Parfois, le code de l’API peut également transmettre au moteur de base de données des commandes SQL générées de façon dynamique.

Dans les bases de données NoSQL, le code d’application de l’API envoie les commandes par l’intermédiaire du pilote de base de données. Par exemple, une application Java peut demander à la bibliothèque de pilotes HBase d’envoyer des commandes CRUD à la base de données. En arrière-plan, le pilote convertit les commandes Java et les exécute sur la base de données.

Exemple concret d’opérations CRUD

Examinons un exemple concret d’opération CRUD. Lorsqu’un utilisateur réserve un voyage à l’aide d’une application en ligne, celle-ci crée (create) un enregistrement de réservation, lit (read) les informations de disponibilité de l’hôtel et de la chambre, met à jour (update) la liste des chambres disponibles une fois la réservation confirmée ou supprime (delete) l’ensemble de l’enregistrement si l’utilisateur annule sa demande. La procédure est similaire pour toute application de traitement de transactions.

REST : de quoi s’agit-il ?

REST est un style d’architecture destiné aux API souvent utilisé dans les applications distribuées. Les API REST (ou RESTful) sont des applications qui respectent les principes de l’architecture REST et autorisent les interactions avec des applications client et d’autres API via leurs endpoints. Les applications qui accèdent à des API RESTful utilisent généralement des méthodes fondées sur le protocole HTPP pour envoyer leurs requêtes. L’architecture REST est régie par six grands principes :

  1. Interface uniforme : cette interface permet à tout client API de communiquer avec le serveur de manière cohérente et normalisée, quel que soit le client ou le langage de programmation ou l’implémentation du serveur.
  2. Client-serveur : le schéma de conception client-serveur attribue des rôles distincts au client et au serveur API. Le serveur est chargé des fonctionnalités backend, telles que le stockage, la validation et l’authentification des données. Le client gère quant à lui l’interface utilisateur, la création de requêtes, etc.
  3. Absence d’état (stateless) : en vertu de ce principe, chaque requête du client à l’API doit contenir toutes les informations nécessaires au serveur pour exécuter la tâche. Le serveur n’enregistre aucune information d’état de session sur le client ou le serveur. Pour l’API, chaque requête du client est nouvelle et indépendante de la requête précédente.
  4. Mise en cache : en vertu de cette contrainte, la réponse fournie par l’API détermine si le client est autorisé à mettre en cache la réponse de l’API. L’API indique si la réponse peut être ou non mise en cache.
  5. Système multicouche : ce principe fait référence à l’inclusion de composants facultatifs offrant des fonctionnalités supplémentaires, telles que l’équilibrage de charge, la validation, etc. Ces couches doivent être transparentes pour le client. Les composants d’une couche donnée ne peuvent voir que la couche avec laquelle ils interagissent.
  6. Code à la demande (en option) : cette fonctionnalité permet aux clients de télécharger et d’exécuter du code depuis le serveur API.

Les API REST sont couramment utilisées dans les applications modernes, comme les API météo, les services de streaming vidéo, les réseaux sociaux et les applications de covoiturage.

Méthodes HTTP

Les clients rédigent les requêtes API RESTful au moyen de méthodes HTTP :

  • GET : la requête GET demande à l’API de récupérer une ressource, telle qu’un enregistrement de base de données ou le contenu d’un fichier, et de l’envoyer au client.
  • POST : la requête POST permet au client d’envoyer des données au serveur API, qui utilise celles-ci pour créer une ressource.
  • PUT : lorsque le client envoie une requête PUT, il renvoie vers l’URI d’une ressource spécifique et fournit des données dans le corps de la requête. Lorsque le serveur API reçoit la requête PUT, il vérifie si la ressource existe. Si c’est le cas, l’API met à jour la ressource à l’aide des données contenues dans la requête PUT. Dans le cas contraire, l’API crée la ressource en s’appuyant sur les données fournies.
  • PATCH : cette requête a pour but d’effectuer une mise à jour partielle d’une ressource existante.
  • DELETE : cette requête est utilisée pour supprimer une ressource existante.

Exemple de requêtes API REST

Plusieurs outils client permettent d’envoyer des requêtes à des endpoints d’API, dont l’outil de ligne de commande courant cURL. Voici quelques exemples d’utilisation de cURL pour envoyer des requêtes HTTP à un endpoint d’une API REST fictive.

L’endpoint de notre API REST fictive est http://www.foobar.com, et nous envoyons différentes requêtes HTTP à cette API pour créer, lire, mettre à jour ou supprimer des enregistrements client.

Dans l’extrait de code suivant, le client cURL demande des informations sur un client portant l’ID 19 au moyen d’une requête GET.

curl -v http://www.foobar.com/find_customert_record?id=19

Nous ajoutons ensuite un enregistrement client à l’aide d’une requête POST. Dans l’exemple de commande ci-dessous, nous intégrons les données dans le corps de la requête HTTP.

curl -X POST -d 'id=10&customer_name=joe_bloggs' http://www.foobar.com/add_customer_record

Dans cet exemple, nous renvoyons vers un fichier qui contient les données nécessaires pour la création de l’enregistrement.

curl -X POST -d @customer_record.json -H "Content-Type: application/json" http://www.foobar.com/add_customer_record

Pour mettre à jour l’enregistrement client, nous envoyons les requêtes PUT suivantes.

curl -d 'id=10&client_name=jane_bloggs' -X PUT http://www.foobar.com/update_customer_record

Enfin, nous supprimons le client portant l’ID 22 :

curl -X DELETE http://www.foobar.com/delete_customer_record?id=22

CRUD et REST : similitudes et différences

Comme vous pouvez le constater, malgré leurs différences, les opérations d’API RESTful peuvent être très similaires aux opérations CRUD de base de données.

Dans l’exemple d’application de voyage en ligne ci-dessus, une application web exécute les opérations CRUD (Create, Read, Update et Delete). Le site web front-end lance les requêtes d’API REST, qui sont ensuite converties par le code de l’API en commandes CRUD de base de données et transmises au pilote de base de données. Une fois que le pilote de base de données renvoie une réponse (positive ou négative), le code de l’API la convertit en réponse HTTP et l’envoie au client.

Qu’il s’agisse d’opérations REST ou CRUD, une réponse est envoyée à la partie requérante. Dans le cas des clients d’API REST, cette réponse prend la forme d’une réponse HTTP standard (par exemple, 200 OK, 404 Resource Not Found, 500 Internal Server Error). Pour les opérations CRUD, chaque moteur de base de données possède ses propres codes de réponse en cas de succès, d’échec ou d’avertissement.

Intéressons-nous à présent aux différences.

Nous avons déjà indiqué que les opérations CRUD et REST sont exécutées en différents endroits de la structure applicative. Avec les API REST, les charges actives sont reçues via le protocole HTTP, tandis que les opérations CRUD utilisent n’importe quel protocole pris en charge par la base de données. Les paquets réseau présentent également des structures différentes. En général, les API REST acceptent les requêtes client sur le port 80 ou 443, même si ce paramètre est configurable. Pour les opérations CRUD, c’est la configuration du serveur de base de données qui détermine le port. Par exemple, pour SQL Server, le port par défaut est 1433.

Un code d’API REST peut contenir des fonctions CRUD. Les API REST ne se limitent toutefois pas à invoquer des opérations CRUD et peuvent exécuter d’autres fonctions, des sous-routines et même d’autres API.

S’il existe d’innombrables API REST (publiques et privées), le nombre de moteurs de base de données est en revanche limité à l’heure actuelle (RDBMS, NoSQL et bases de données en mémoire).

Journalisez toutes vos données et répondez à toutes les questions – gratuitement

Falcon LogScale Community Edition (anciennement Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.

Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :

  • Ingestion de jusqu’à 16 Go de données par jour
  • Durée de rétention de 7 jours
  • Aucune carte de crédit n’est requise
  • Accès continu sans période d’essai
  • Journalisation sans index, alertes en temps réel et tableaux de bord en direct
  • Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
  • Formation et collaboration avec une communauté active

Démarrer gratuitement

À PROPOS DE L'AUTEUR

Arfan Sharif est responsable du marketing produits pour le portefeuille d’observabilité chez CrowdStrike. Il possède plus de 15 ans d’expérience dans les solutions de gestion des logs, ITOps, d’observabilité, de sécurité et d’expérience client pour des entreprises telles que Splunk, Genesys et Quest. Arfan est titulaire d’un diplôme en informatique de la Buckinghamshire New University, et a travaillé aussi bien dans le marketing produits que dans l’ingénierie commerciale.