Cette page a été traduite de l’anglais.
Outils pour développeurs
Créez un outil de test et de débogage d'API
Kliv est un créateur d'applications par IA. Décrivez l'outil de test et de débogage d'API dont votre équipe a besoin — requêtes enregistrées, sondes planifiées, différences de réponse, incidents et cloisons partenaires — et il le construit.
Entrez simplement votre idée dans la zone de texte et AI la construira pour vous
Qu'est-ce que Kliv ?
Kliv n'est pas un client API de bureau ni un service de collections partagées : c'est une IA qui crée des logiciels pour vous.
Vous décrivez l'application dont vous avez besoin en langage courant, et Kliv construit la base de données, la logique, les écrans, les tâches planifiées et les règles d'accès. Vous êtes propriétaire du résultat et pouvez le faire évoluer par la suite en demandant des modifications. Ce n'est pas un espace de travail à partir d'un modèle.
Sur cette page, cette application est un atelier de test et de débogage d'API. Kliv crée toutes sortes d'applications web ; celle-ci aide une équipe à se souvenir des requêtes, à exécuter des sondes, à comparer les réponses et à relier les incidents aux preuves.
Pourquoi les collections de requêtes partagées cessent de tenir la charge
Un client API sur chaque ordinateur peut convenir pour une intégration et deux ingénieurs. Cela cesse de fonctionner dès qu'il y a de nombreuses API partenaires, des collègues dans des fuseaux horaires différents, et des clients qui demandent si la panne vient de votre code ou d'un changement chez le partenaire.
Kliv construit l'atelier comme un système de référence. Chaque point de terminaison, requête enregistrée, résultat de sonde, différence de réponse et incident est une ligne dans une base de données partagée, avec des permissions et un historique qui survivent au-delà de l'ordinateur d'une seule personne.
Les éléments d'une requête
Cinq enregistrements transforment une requête enregistrée en processus de débogage.
Fiches de point de terminaison
URL de base par environnement, méthode d'authentification, contact chez le partenaire, et le journal des modifications que vous tenez à jour. Les requêtes et les incidents se rattachent à cet enregistrement.
Requêtes enregistrées
En-têtes, corps, et assertions telles que le statut attendu, la forme attendue et le plafond de latence. Une requête devient un test dès qu'elle a des assertions.
Plannings de sondes
Des fonctions côté serveur rejouent les requêtes enregistrées selon un planning, par exemple toutes les quinze minutes sur la préproduction et toutes les heures sur la production. Une assertion en échec ouvre un incident.
Incidents
Un incident conserve la différence de réponse, la chronologie, les marchands concernés, et qui a été informé, et quand.
Cloisons partenaires
Les ingénieurs voient les partenaires qui leur sont attribués. Une vue de statut client montre ses propres intégrations et rien au-delà.
Un exemple : l'équipe d'intégrations logistiques de Léa
Voici comment une équipe pourrait utiliser un atelier de test d'API construit avec Kliv. Ce n'est qu'un exemple : vous décririez vos propres partenaires, requêtes, environnements, assertions et règles d'incident.
Un partenaire modifie une réponse sans prévenir
Un transporteur déploie en préproduction et l'en-tête de version passe de 2.13 à 2.14. Aucun e-mail, aucune entrée de journal des modifications de la part du transporteur.
La sonde planifiée détecte le changement de forme
La sonde de Léa constate que la charge utile de suivi a gagné un champ et en a perdu un autre. Le point de terminaison renvoie toujours 200, mais l'assertion sur la forme échoue.
L'incident s'ouvre avec la différence jointe
Les marchands concernés sont identifiés à partir des données, car seuls deux d'entre eux font transiter leur fret par ce transporteur. La gravité ne repose pas sur des suppositions.
L'équipe rejoue la préproduction et la production côte à côte
Le lundi, la requête enregistrée s'exécute sur les deux environnements dans une seule vue. Le changement est circonscrit, le correctif est une mise à jour de mapping, et l'investigation reste sur un seul écran.
Le client lit une chronologie limitée à son périmètre
Le marchand voit sa propre page d'incident : ce qui a changé, quand l'équipe l'a su, et ce qui a été fait. Les intégrations des autres marchands ne sont pas visibles.
Décrivez l'atelier API que vous voulez
Kliv construit à partir de votre description ; indiquez donc les partenaires, les environnements, les plannings, les assertions, les règles d'incident, et qui peut voir quoi. Plus vous donnez de détails, plus la première version sera proche du but.
Atelier API transporteur
Requêtes enregistrées, sondes et incidents pour les partenaires logistiques.
“Construis un atelier de test d'API pour nos intégrations logistiques. Enregistre les requêtes par transporteur, stocke les URL de base de préproduction et de production, exécute des sondes en préproduction toutes les 15 minutes, exécute des sondes sûres pour la production toutes les heures, vérifie le statut 200, les champs de suivi requis et une latence inférieure à 800 ms, et ouvre des incidents avec les différences de réponse complètes et les marchands concernés.”
Surveillance du bac à sable de paiement
Surveillez un partenaire de paiement avant la mise en production.
“Construis un moniteur d'API de paiement qui rejoue nos requêtes enregistrées d'autorisation, de capture, de remboursement et de vérification de webhook toutes les heures sur le bac à sable. Vérifie la forme de la réponse, le statut et une latence inférieure à 500 ms, et ouvre un incident avec la différence dès qu'une assertion échoue.”
Portail de statut client
Donnez à chaque marchand son propre historique d'intégration.
“Construis un portail de statut client où chaque marchand se connecte pour voir la disponibilité, les incidents et l'historique des sondes de ses propres intégrations uniquement. Envoie des mises à jour par e-mail quand un incident s'ouvre, change de statut ou se résout.”
Sous la console
Les sondes sont des tâches planifiées. Chaque sonde est une fonction côté serveur sur un cron. Elle rejoue la requête enregistrée, évalue les assertions, et écrit le résultat sous forme de ligne.
Les clés partenaires restent côté serveur. Les clés du bac à sable et de production sont stockées par la plateforme et injectées au moment de l'exécution. Elles ne se trouvent ni dans des collections exportées, ni sur des ordinateurs, ni dans des wikis. Une sonde de préproduction ne peut pas s'exécuter avec des clés de production si vous séparez bien les environnements.
Les cloisons sont des règles de données. Un ingénieur limité à deux transporteurs ne récupère que ces deux transporteurs depuis les mêmes tables. Un client voit sa propre vue de statut. La règle de confidentialité s'applique avant que les lignes ne soient servies.
Comme il s'agit d'une application, elle peut évoluer vers de nouvelles surfaces qu'un client peut utiliser : pages de statut marchand, résumés hebdomadaires des sondes, et un agent qui répond à « quand l'API tarifaire a-t-elle changé pour la dernière fois ? » à partir de votre propre historique d'incidents.
Kliv rédige aussi des tests pendant la construction et peut retenir la publication tant qu'ils ne passent pas. La page sur les tests détaille cette discipline.
Questions fréquentes
Qu'est-ce que Kliv, exactement ?
Kliv est un créateur d'applications par IA. Vous décrivez le flux de test d'API dont vous avez besoin, et il construit une véritable application avec requêtes enregistrées, plannings de sondes, incidents, différences et vues limitées.
Est-ce que j'obtiens une vraie application, ou un modèle ?
Une vraie application. Vos points de terminaison, assertions, plannings, environnements, incidents et règles d'accès sont stockés dans une base de données construite pour votre flux de travail.
Puis-je la modifier après sa construction ?
Oui. Vous pouvez ajouter des partenaires, des assertions, des plannings, des champs d'incident, des vues client ou de nouveaux environnements en demandant des modifications en langage courant.
Les sondes peuvent-elles s'exécuter en production sans causer de dégâts ?
Oui. Vous marquez quelles requêtes enregistrées sont sûres pour la production. Les requêtes qui modifient des données peuvent rester réservées à la préproduction, et chaque environnement porte ses propres clés.
Les clients peuvent-ils voir l'atelier ?
Ils peuvent voir une vue limitée : leurs propres intégrations, incidents, disponibilité et historique des sondes. Les ingénieurs conservent la console complète.
Que se passe-t-il quand une assertion échoue à 3 heures du matin ?
Une ligne d'incident est créée avec la différence de réponse jointe. Un e-mail ou Slack peut prévenir l'ingénieur d'astreinte, et la sonde continue de tourner pour que la reprise soit enregistrée.
Pouvons-nous importer des collections de requêtes existantes ?
Oui. Les requêtes enregistrées sont des données. Les importer leur donne des plannings, des assertions, des incidents et des règles d'accès au lieu de les laisser sous forme de fichiers sur un ordinateur.
Peut-elle stocker les secrets en toute sécurité ?
Les clés d'API restent côté serveur et sont injectées à l'exécution d'une sonde. Elles n'ont pas besoin d'être exportées avec les définitions de requêtes.
Puis-je utiliser mon propre domaine ?
Oui. Les consoles internes et les vues de statut client peuvent tourner sur votre propre domaine.
Puis-je quitter Kliv plus tard ?
Oui. Le code de l'application se synchronise avec votre propre dépôt Git, donc partir revient à faire un git pull plutôt qu'à tout reconstruire.
Ai-je besoin d'un outil d'incident séparé ?
Non, pas pour le flux de travail décrit ici. Les incidents peuvent vivre dans la même application que les sondes, les différences et les chronologies visibles par les clients.
Plus dans cette catégorie
Réalisé par des créateurs
Découvrez ce qui est possible
Découvrez de vraies applications créées avec Kliv par des développeurs et des créateurs du monde entier
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Repérez le changement de version avant vos clients
Décrivez comment votre équipe teste les API — partenaires, requêtes, sondes, assertions et cloisons. Kliv construit l'atelier qui s'en souvient.