J’ai récemment fait une présentation sur l’utilisation du cloud et des API REST de Delphi lors de la conférence italienne Delphi Day, fin juin. Parmi les différentes démos, j’ai fait quelques expériences en utilisant les API APILayer REST. Au cas où vous ne le sauriez pas, APILayer est une entreprise qui fait partie d’Idera, comme Embarcadero.
Table des matières
Pourquoi les API REST
Avant d’explorer des API et des démos spécifiques, j’aimerais discuter de la pertinence d’utiliser des API dans le contexte d’une application cliente comme celles construites avec Delphi. Dans le passé, la manière la plus courante d’ajouter une fonctionnalité à un programme consistait à écrire le code approprié ou à utiliser une bibliothèque existante pour ajouter la fonctionnalité, et à distribuer le code compilé de la fonctionnalité avec l’application.
Les services en ligne et les API REST d’aujourd’hui offrent souvent des fonctionnalités similaires activées en transmettant les paramètres appropriés avec un appel HTTP à un serveur et en recevant le résultat. Les exemples incluent les transformations d’images, la création d’un PDF, la transformation de texte en parole ou la lecture du texte intégré dans une image.
Pourquoi utiliseriez-vous une approche plutôt qu’une autre ? Il existe des cas dans lesquels une seule des alternatives est réaliste (un rendu graphique performant nécessite une bibliothèque graphique installée alors qu’une capacité d’IA est généralement disponible en ligne), mais dans d’autres scénarios, les deux approches peuvent être possibles.
L’utilisation d’une bibliothèque locale a l’avantage de :
- Exécution généralement plus rapide
- Pas besoin de connexion Internet
- Peut-être la capacité d’affiner et de personnaliser la fonctionnalité et de mieux la lier avec le code et l’interface utilisateur
- Au niveau de la sécurité, vous n’avez pas à vous soucier du cryptage de la communication pour éviter que quelqu’un n’accède aux données de l’application en transit
L’utilisation d’une API REST a l’avantage de :
- Garder l’application plus petite, car vous n’avez pas besoin de distribuer du code de bibliothèque supplémentaire
- Utilisez toujours la dernière version de la bibliothèque, car elle peut être mise à jour séparément de l’application cliente
- Au niveau de la sécurité, vous n’avez pas à vous soucier de la mise à jour de la bibliothèque en cas de découverte d’un problème, vous devez déployer une nouvelle version de l’application
Enfin, il existe souvent une différence entre les coûts d’une bibliothèque et d’une API REST :
- À moins que la bibliothèque ne soit gratuite et open source, elle aurait généralement un coût initial fixe par développeur
- La plupart des API REST ont un modèle de paiement à l’utilisation, souvent avec un niveau gratuit que vous pouvez utiliser pour le développement et les tests
- Ainsi, l’API REST peut être moins chère pour une utilisation limitée, mais devenir plus chère pour une utilisation intensive
Présentation de APILayer
APILayer est une entreprise Idera axée sur l’offre d’API hébergées et sur la création d’un marché d’API, hébergeant également des API tierces. Vous pouvez en savoir plus sur les nombreux services disponibles sur https://apilayer.com/
Il existe de nombreuses API puissantes dans le cadre d’APILayer, et si certaines ont plus de sens dans une application Web (comme IpStack), beaucoup d’autres ont également un sens parfait dans une application cliente, comme les services de traitement de fichiers proposés par FileStack ( https://www .filestack.com/ ) ou l’api de vérification des e-mails tiers astucieux ( https://apilayer.com/marketplace/email_verification-api ).
Dans ma démo ci-dessous, je vais me concentrer sur une API simple, peut-être pas la plus puissante : WeatherStack, qui, comme son nom l’indique, peut fournir des données actuelles, historiques et prévisionnelles sur la météo :
Utilisation du débogueur REST de RAD Studio
Une fois que vous avez identifié l’API REST que vous envisagez d’utiliser, le moyen le plus simple de commencer à développer une application cliente consiste à utiliser le débogueur REST, disponible dans le cadre de l’installation de RAD Studio (et accessible depuis le menu Outils) et également en téléchargement gratuit séparé. pour n’importe qui ( https://www.embarcadero.com/free-tools/rest-debugger ).
Le débogueur offre la possibilité de configurer une API REST, d’enregistrer cette configuration pour une utilisation future (ou de la partager avec un autre développeur) et d’importer la configuration dans une application Delphi ou C++Builder.
Dans un cas simple, comme celui de WeatherStack, après avoir démarré le débogueur REST, vous devez d’abord configurer le point de terminaison principal :
Ensuite, vous devez définir la configuration des paramètres appropriés, y compris le point de terminaison spécifique (actuel), le paramètre de requête et les informations d’authentification access_key :
Les paramètres dépendent du point de terminaison et sont répertoriés dans la documentation de l’API. À ce stade, vous pouvez utiliser le bouton SendRequest pour essayer l’API et vérifier la réponse dans la partie inférieure de l’interface utilisateur du débogueur REST :
La structure de données résultante est relativement complexe, mais nous pouvons filtrer certaines des tables imbriquées (comme l’emplacement visible ci-dessus) dans une structure de table. Étant donné que nous recherchons probablement les données actuelles, nous pouvons utiliser cet élément racine JSON pour obtenir les données dans une structure de table :
Construire une démo réelle dans Delphi
Une fois que vous êtes satisfait de la configuration et des données A (y compris éventuellement les données de la table), vous pouvez utiliser le bouton Copier le composant du débogueur REST pour rationaliser le développement d’une application. Ce bouton, en fait, capture la configuration des composants de la bibliothèque cliente REST et vous permet de la coller dans un formulaire ou un module de données dans l’IDE RAD Studio.
Dans ce cas, je viens de créer une application FireMonkey simple avec Delphi, d’ajouter un module de données et d’y coller la configuration des composants. Il en résulte le module de données suivant :
La configuration réelle des composants est la suivante :
[crayon-673f83e506e8d400171889/]
Comme vous le voyez, le composant RESTClient a la configuration globale du site, le RESTRequest fait référence au point de terminaison et à ses paramètres, le composant optionnel RESTResponse contient les résultats et peut le transmettre via le composant RESTResponseDataSetAdapter à une table en mémoire, le FDMemTable composant.
À ce stade, ce dont vous avez besoin dans le formulaire principal est un bouton pour effectuer l’appel et une zone d’édition avec l’emplacement et un composant d’affichage (j’ai utilisé une zone d’édition en lecture seule). Dans le gestionnaire d’événements OnClick du bouton, vous pouvez écrire du code comme celui-ci :
[crayon-673f83e506e98943747440/]
Comme alternative, vous pouvez lier l’entrée et la sortie via Visual LiveBindings, en connectant l’édition d’entrée aux paramètres de la requête et le champ spécifique de la table en mémoire au contrôle de sortie. Pour pouvoir le faire, vous devez d’abord exécuter la requête HTTP au moment de la conception, à l’aide d’une commande spécifique du composant RESTRequest. Cela remplit les métadonnées des composants, y compris la table en mémoire. Après l’avoir fait, vous pouvez câbler l’entrée et la sortie dans le concepteur LiveBindings, et résider le code exécuté en appuyant sur le bouton pour :
[crayon-673f83e506e9a687143014/]
Voici la configuration du concepteur LiveBindings :
Et enfin, voici l’application à l’exécution, en cette chaude journée d’été :
Conclusion
Comme vous l’avez vu, implémenter un client pour une API REST dans Delphi est relativement simple (j’ai déjà démontré la même chose dans le passé en couvrant une API différente ici ). Maintenant, dans le cas d’une application météo, il n’y a pas beaucoup d’alternatives par rapport à l’accès aux données en direct à partir d’un service Web, tandis que dans d’autres scénarios, l’utilisation d’une API serait une alternative par rapport à l’intégration de la même fonctionnalité dans une partie bibliothèque de l’application.
Nous prévoyons de présenter quelques autres API d’APILayer sur le blog Embarcadero, alors restez à l’écoute et n’hésitez pas à partager vos idées avec nous.