Lorsque vous effectuez une recherche sur le Web pour "comment créer une API", j'ai constaté que de nombreuses options se présentaient, mais très peu sont des guides de bout en bout. Cela peut être dû à mes faibles capacités de recherche sur le Web ou parce qu'il est assez difficile de créer une API (de la conception à la production). Quiconque travaille avec des API vous dira que cela peut être tout un exploit, et une équipe de personnes le gère généralement. Ainsi, créer vous-même une API et la mettre en production afin que vos utilisateurs puissent commencer à l'utiliser peut être un défi de taille. Nous vivons à une époque chanceuse où il existe de nombreux outils qui rendent cette tâche beaucoup plus gérable. Avec quelque chose comme Postman, nous pouvons créer la spécification de l'API, tester la spécification de l'API et finalement tester notre API pour nous assurer qu'elle fonctionne comme prévu. Pour construire le back-end de notre API, nous aurons besoin d'une multitude d'outils tels que Flask, Heroku et plus, ou nous pouvons opter pour un outil low-code pour construire et héberger notre API. Dans cet article, nous examinerons le processus de création d'une API et comment ce processus peut être rendu plus efficace. Processus de développement d'API Le développement d'API est complexe, il n'y a pas moyen de le contourner. En règle générale, nous devons concevoir l'API, coder, tester, déboguer, coder à nouveau, tester encore plus, déployer lorsque nous sommes prêts, puis il y a la maintenance apparemment sans fin. Un cycle de vie typique de développement d'API ressemblera à ceci : Chaque étape du processus sera généralement effectuée par un autre outil ou ressource, de sorte que la mise en œuvre d'une API peut devenir une tâche ardue. Par exemple, nous pourrions choisir d'utiliser Postman pour concevoir notre API (Open API Specification) et utiliser quelque chose comme flask pour notre code connect firebase ou une base de données pour stocker ou récupérer nos données. Nous pourrions également avoir besoin d'effectuer des appels REST supplémentaires vers d'autres API et services. Pour tester, nous pouvons à nouveau utiliser Postman, mais le débogage du code et de tous nos connecteurs peut devenir gênant. Pour le déploiement, nous pouvons opter pour Heroku, mais cela dépend de ce que notre API requiert. Pour la surveillance, nous pouvons soit créer notre système de surveillance, soit utiliser quelque chose comme Splunk. Et lorsque nous devons maintenir notre API, nous devons nous replonger dans tout cela. Vous comprenez ce que j'essaie de dire. Le développement d'API est compliqué. Trouver une meilleure façon Je voulais un moyen de simplifier le cycle de vie du développement d'API et de développer mes API de la conception à la production avec seulement une poignée d'outils. Grâce à des outils low-code comme Linx, c'est possible. J'ai pu créer une API, de la conception au déploiement, en utilisant seulement trois outils : Postman J'ai utilisé postman pour créer ma spécification d'API (basée sur YAML) et pour tester mon API Linx j'ai utilisé pour construire mon API, implémenter la logique, la déboguer et enfin l'héberger. Remarque rapide, vous pouvez également vous essayer à la création d'une API avec ce didacticiel guidé. Linx SQL Server SQL Server a été utilisé pour stocker des données pour mon API. J'ai utilisé la base de données AdventureWorks2019 pré-créée et ses données. L'exigence J'ai opté pour une API simple qui effectuera la maintenance des enregistrements des utilisateurs. L'API a cinq méthodes : Création du cahier des charges J'ai créé une spécification d'API simple dans Postman en utilisant YAML qui correspond à l'exigence. Postman m'a permis de voir ce que j'ai créé et a fourni visuellement des informations supplémentaires. La création de la définition d'API dans Postman bénéficie également du fait qu'elle configure déjà cette API pour les tests. Si vous le souhaitez, vous pouvez configurer les scripts de test à ce stade. Construire l'API Maintenant que j'ai la définition de l'API, le code peut être créé. Linx vous permet d'importer une spécification OpenAPI 3.0 et générera automatiquement les événements pour chaque méthode spécifiée. J'avais seulement besoin de spécifier l'URI, puis de construire la logique. La création de la logique de chaque événement est relativement rapide une fois le plug-in de base de données installé. Linx a une courbe d'apprentissage comme tout outil, mais une fois que vous avez compris comment l'utiliser, le rythme s'accélère. J'ai ajouté une logique et des fonctionnalités à chaque événement pour l'API. Par exemple, pour la méthode GetAllUsers, nous devions tous lire à partir de la base de données SQL et renvoyer les résultats via le corps de la réponse. Tester l'API Étant donné que l'API est déjà configurée sur Postman, il était assez facile de tester, en temps réel, le fonctionnement de l'API maintenant que la logique a été implémentée. Le GIF ci-dessous montre comment j'ai utilisé le concepteur Linx pour déboguer l'API REST que j'ai créée et comment je le teste en mode débogage. GIF L'API étant déboguée dans Linx, elle est hébergée afin que je puisse l'appeler pour voir comment elle se comportera lors du déploiement. Cela me permet de tester et d'obtenir un résultat réel: Bien sûr, nous pouvons également ajouter des scripts de test dans Postman pour automatiser notre processus de test. Ces scripts garantiront que vous obtenez la bonne réponse. Déploiement de l'API Maintenant que l'API a été conçue, développée et testée, elle doit être déployée. Cela peut être une tâche importante avec le développement d'API traditionnel car nous devons proposer une stratégie de déploiement, déterminer où nous hébergerons quoi et nous assurer que la surveillance et la journalisation sont prises en charge et plus encore. Mon déploiement a été assez simple. J'ai déployé l'API du concepteur Linx directement sur le serveur Linx. Il a fallu environ 2 minutes pour que la solution soit construite, poussée sur le serveur et prête à l'emploi. La difficulté d'héberger une API est supprimée car le serveur Linx gère cela. Il effectue également la surveillance et la journalisation : J'ai appelé la méthode GetUser avec un ID incorrect pour voir ce qui se passerait si une erreur inattendue se produisait. Le serveur enregistre l'erreur et indique en rouge qu'une erreur s'est produite : J'ai pu appeler à nouveau l'API depuis Postman, et le serveur donne une indication à chaque fois que l'API est appelée. Certes, je n'ai ajouté aucune forme de sécurité ou d'authentification à mon API, mais ces paramètres sont disponibles dans le concepteur Linx. Une autre option que j'ai essayée était de générer la documentation de l'API au format swagger. Cela s'est avéré très utile car en ajoutant /swagger à l'URI de base, la documentation est disponible et hébergée avec l'API elle-même. Cela facilite la distribution de la documentation de l'API en cas de besoin. Emballer En combinant Linx et Postman, nous pouvons concevoir, créer, documenter et héberger des API. Il faut un peu de temps pour s'y habituer, comme n'importe quel outil. Étant donné que Linx utilise des paradigmes de programmation et un jargon standard, il est facile à comprendre si vous êtes familier avec un langage de programmation comme C#. Je pense que nous gagnons le plus de temps lors du déploiement et de l'hébergement d'une API avec Linx. La surveillance et l'hébergement sont faits pour vous, ce qui signifie qu'un casse-tête substantiel est pris en charge. Si la journalisation et la surveillance ne sont pas suffisamment granulaires, vous pouvez ajouter votre fonctionnalité à la solution Linx. Si vous voulez essayer de construire une API avec Linx, vous pouvez l'essayer vous-même utilisant (avec facteur) ou concevoir d'abord (il suffit de construire) coder d'abord Également publié . ici
