RAD Studio 11 a vu l’introduction de TRESTRequestDataSetAdapter, un composant qui peut lire les données d’un TDataSet et les convertir en JSON prêt à être renvoyé à une API RESTful distante. Avant de parler davantage de son utilisation, je souhaite récapituler le fonctionnement des URL/API REST.
API REST et VERBES
Les API REST sont généralement créées pour utiliser les différents verbes HTML (POST, GET, PUT, PATCH et DELETE) pour définir le type de demande adressée à un point de terminaison.
Par exemple, imaginons que vous gérez une liste de tâches dans une base de données qui sont soit complètes soit incomplètes. Une URL d’API de base telle que « https://<myURL>/data/tasks/ » pourrait fournir un point de terminaison à appeler pour travailler avec les données TASK, et les différents verbes sont ensuite utilisés lors de l’appel du point de terminaison pour définir le type d’action événement. (par exemple, récupérer des données, insérer, mettre à jour ou supprimer des données). Pour que cela fonctionne, certains verbes nécessitent une valeur d’ID pour identifier les données avec lesquelles vous souhaitez travailler (par exemple, quel enregistrement mettre à jour / supprimer ?), donc en réalité, l’URL de certaines tâches prendrait également une valeur d’ID facultative, par exemple » /données/tâches/{id} »
Pour renvoyer les données au serveur à l’aide de TRESTRequestDataSetAdapter, il est d’abord important de faire correspondre l’opération (insérer, mettre à jour, supprimer) au bon verbe, puis d’utiliser TRESTRequest pour exécuter avec les données JSON correctement formées, mais aussi pour assurer le point de terminaison a le bon point de terminaison défini.
En utilisant cette dénomination standard pour les URL (ci-dessus), plus le TRESTRequestDataSetAdapter, il est possible d’empaqueter le JSON avec peu de code pour renvoyer les données au serveur. Le TRESTRequestDataSetAdapter connecte un TRESTRequest et un TDataSet. La propriété Area définit ce qui est sélectionné (par exemple, All ou Current record) et convertit l’ensemble de données en contenu JSON qui doit être renvoyé au serveur.
Pour ce faire automatiquement, vous pouvez utiliser les événements sur le TDataSet, par exemple AfterInsert, AfterPost et BeforeDelete, pour récupérer les modifications dans l’ensemble de données, puis effectuer des appels à distance pour maintenir la synchronisation du serveur.
POURTANT…. Et si vous avez des problèmes de connexion ?
Bénéficiant du développement natif pour rendre les applications REST plus riches en fonctionnalités.
Une fonctionnalité utile de FireDAC (et d’autres ensembles de données tels que TClientDataSet) est l’option CachedUpdate. En utilisant CachedUpdates, vous pouvez suivre les modifications à l’intérieur d’un ensemble de données. Cela permet aux modifications d’être mises en cache, enregistrées localement, puis repoussées ultérieurement. (idéal si la connectivité est limitée).
Il est possible de combiner ces excellentes fonctionnalités des bibliothèques natives avec TRESTRequestDataSetAdapter pour enregistrer les modifications sur le serveur. Bien que cela puisse ajouter plus de complexité, en particulier lorsque vous avez des opérations d’insertion, de mise à jour et de suppression combinées dans le même cache (car celles-ci utilisent différents VERBS pour mettre à jour le serveur distant), il est possible de filtrer un cache de données pour traiter chaque type de mise à jour dans tourner.
Pour vous montrer comment faire cela, j’ai créé un exemple disponible via GitHub – Cela inclut une unité REST.RESTUpdater avec des classes d’aide pour gérer le transport et l’affichage des données en seulement quelques lignes de code ! – En savoir plus sur l’exemple sur ce post
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
