⭐ La version de mai se concentre sur des améliorations pratiques : moins de configuration après migration, plus de sécurité pour l’authentification en entreprise, et des résultats de débogage API plus complets au quotidien.
Lorsque les équipes déplacent leur travail API entre différents outils, le plus dur n’est généralement pas l’import des fichiers. Le vrai travail commence après : corriger les URL de base, configurer les environnements, ajuster le code généré avec l’authentification, puis faire fonctionner les runners CI avec des règles d’infrastructure plus strictes.
Essayez Apidog dès aujourd’hui
Cette version d’Apidog cible directement ces points de friction. Les imports Postman détectent mieux les URL de base, les Politiques d’entreprise introduisent des contrôles de sécurité d’authentification, le Mode Spec-First peut être testé sans Git, Runner peut s’exécuter sans privilèges root, le code de requête généré peut inclure l’authentification, et plusieurs problèmes liés au partage de requêtes, aux tests automatisés et aux données Mock ont été corrigés.
Voici les changements à appliquer dans vos workflows.
⭐ Nouvelles mises à jour
📦 Importer des données Postman avec une meilleure détection des URL de base
Lors d’un import Postman, Apidog peut désormais détecter plus intelligemment une URL de base partagée et la placer dans le champ URL de base du module correspondant, dans les environnements concernés.
Comment l’utiliser
- Importez vos collections Postman dans Apidog.
- Utilisez soit :
- un fichier Postman local ;
- le chemin d’importation via l’API Postman.
- Vérifiez les environnements générés.
- Contrôlez que les URL de base détectées sont bien placées dans le champ URL de base du module.
- Lancez quelques requêtes critiques pour valider la migration.
| Avant | Maintenant |
|---|---|
| Importer les collections depuis Postman. | Importer des fichiers Postman ou utiliser l’import via l’API Postman. |
| Vérifier manuellement les URL de requête. | Apidog détecte les URL de base partagées lorsqu’il peut le faire de manière fiable. |
| Remplir les URL de base du module pour chaque environnement. | Les valeurs détectées sont placées dans le champ URL de base du module correspondant. |
| Corriger les requêtes cassées avant les tests. | Les requêtes importées sont plus faciles à exécuter immédiatement. |
Cette amélioration est utile si vos requêtes Postman utilisent des structures comme :
https://api.example.com/v1/users
https://api.example.com/v1/orders
https://api.example.com/v1/payments
ou des variables reconnaissables pour factoriser l’hôte ou le préfixe d’API.
Résultat : après l’import, vous passez moins de temps à corriger chaque requête une par une et davantage de temps à valider les appels réellement importants.
🛡️ Gouverner l’authentification avec les Politiques d’entreprise
Apidog introduit les Politiques d’entreprise comme cadre de gouvernance pour les contrôles de sécurité au niveau de l’organisation. Le premier domaine couvert est la Sécurité de l’authentification.
L’objectif est simple : réduire l’exposition des identifiants dans les configurations d’authentification.
Ce que les administrateurs peuvent contrôler
Les administrateurs d’organisation peuvent définir des règles pour les champs d’authentification sensibles, par exemple :
- encourager ou exiger l’utilisation de variables ;
- encourager ou exiger l’utilisation de Secrets Vault ;
- éviter le stockage d’identifiants bruts directement dans les champs d’authentification.
Pour les Secrets Vault, les équipes peuvent aussi empêcher l’affichage en clair dans l’interface. Les membres peuvent toujours référencer le secret lors de l’exécution d’une requête, mais la valeur n’est pas exposée accidentellement via une icône d’affichage ou pendant un partage d’écran.
🔒 Cette mise à jour aide les équipes d’entreprise à gouverner les identifiants d’authentification sans transformer le débogage API en processus de sécurité séparé.
Bonne pratique à appliquer
Au lieu de configurer une clé directement dans une requête :
Authorization: Bearer sk_live_xxxxx
préférez une référence à une variable ou à un secret :
Authorization: Bearer {{API_TOKEN}}
Cela facilite la rotation des secrets, réduit les fuites accidentelles et rend les environnements plus faciles à maintenir.
📝 Tester le Mode Spec-First sans configuration Git préalable
Le Mode Spec-First est désormais plus simple à évaluer. Vous pouvez créer un projet Spec-First sans lier de dépôt Git dès le départ, puis ajouter ou importer un fichier OpenAPI lorsque vous êtes prêt.
Workflow recommandé
- Créez un projet Spec-First dans Apidog.
- Importez ou ajoutez un fichier OpenAPI.
- Validez la structure des endpoints.
- Recueillez les retours de l’équipe.
- Ajoutez Git plus tard si le workflow est confirmé.
Ce changement réduit la barrière d’entrée pour les équipes qui veulent explorer un workflow centré sur OpenAPI avant de standardiser la structure des dépôts.
ℹ️ C’est particulièrement utile pour tester une approche Spec-First, préparer une convention OpenAPI ou obtenir des retours avant d’imposer une organisation Git complète.
🔒 Exécuter Runner avec un utilisateur non-root
Runner prend désormais en charge l’exécution en tant qu’utilisateur non-root.
C’est important pour les environnements serveur, conteneurisés et CI/CD où l’exécution de processus en tant que root est déconseillée ou bloquée par les politiques internes.
Pourquoi c’est utile
Dans de nombreux environnements CI/CD, l’exécution root augmente la surface de risque. Pouvoir lancer Runner avec un utilisateur non privilégié permet de mieux s’aligner avec les pratiques de sécurité courantes.
Exemple de logique côté conteneur :
RUN adduser --disabled-password --gecos "" runneruser
USER runneruser
Vous pouvez ainsi intégrer Runner dans vos automatisations existantes tout en réduisant les permissions accordées au processus.
✅ Cette mise à jour aide les équipes à aligner le déploiement de Runner avec leurs exigences de sécurité internes sans modifier le workflow global des tests.
🔐 Générer du code de requête avec les informations d’authentification
Lors de la génération de code depuis une requête API, Apidog peut désormais inclure les informations d’authentification déjà configurées.
Cas d’usage
Cette amélioration est utile lorsque vous devez :
- vérifier rapidement un appel API hors d’Apidog ;
- partager un exemple exécutable avec un coéquipier ;
- coller une requête dans un script de débogage ;
- reproduire un bug dans un autre environnement.
Avant, vous pouviez générer un extrait puis devoir ajouter manuellement les headers, tokens ou paramètres d’authentification. Maintenant, l’extrait généré est plus proche de la requête réellement configurée.
Exemple de résultat attendu côté usage :
curl --request GET \
--url https://api.example.com/v1/users \
--header 'Authorization: Bearer {{API_TOKEN}}' \
--header 'Content-Type: application/json'
L’objectif n’est pas de remplacer votre gestion des secrets, mais de produire des exemples plus complets et plus faciles à exécuter.
✅ Optimisations
🧩 Exécution de scripts CLI plus restreinte
Pour réduire les risques liés à l’exécution de scripts, la CLI n’autorise désormais l’appel que des scripts provenant du répertoire Programmes externes.
À vérifier dans vos automatisations
Si votre équipe utilise des scripts CLI dans des workflows d’automatisation :
- Identifiez les scripts appelés par la CLI.
- Vérifiez leur emplacement actuel.
- Déplacez-les si nécessaire dans le répertoire Programmes externes.
- Relancez vos jobs CI ou scripts locaux.
- Mettez à jour la documentation interne si les chemins ont changé.
Cette limite réduit les appels trop larges ou accidentels tout en conservant les workflows prévus pour les programmes externes.
📋 Commandes cURL copiées plus complètes
Lors de la copie d’une commande cURL depuis Apidog, la commande générée inclut désormais plus fidèlement les paramètres d’en-tête et de corps configurés.
Exemple de workflow
- Configurez votre requête dans Apidog.
- Ajoutez les headers nécessaires.
- Ajoutez le body si la méthode le requiert.
- Copiez la commande cURL.
- Collez-la dans un terminal ou dans une note de reproduction.
Cela rend la commande copiée plus proche de la requête réelle. Vous avez moins de nettoyage manuel à faire pour reproduire un problème, documenter un cas de test ou partager une requête avec un autre développeur.
🧪 Synchronisation plus fiable des étapes de test automatisées
Lorsqu’une méthode d’endpoint change, par exemple de GET vers POST, PUT ou une autre méthode, les étapes de test automatisées associées synchronisent désormais la configuration mise à jour avec plus de précision.
Pourquoi c’est important
Un changement de méthode peut casser un test si l’étape automatisée conserve une ancienne configuration. Cette mise à jour réduit les incohérences causées par des informations obsolètes.
À appliquer après modification d’un endpoint :
- Changez la méthode de la requête.
- Vérifiez les étapes de test automatisées associées.
- Exécutez le test.
- Confirmez que la méthode utilisée correspond à la configuration actuelle.
Résultat : des tests plus fiables après les changements d’API.
🎲 Génération de données Mock plus stable
Cette version corrige plusieurs problèmes liés à la génération de données Mock, notamment :
- les règles de multiplicateur ;
- les expressions
arrayElements; - les problèmes de génération par lots lorsque la génération JavaScript et la génération Mock sont utilisées ensemble.
Où cela aide le plus
Ces corrections sont utiles pour :
- l’intégration frontend-backend ;
- la génération massive de données de test ;
- les tests automatisés ;
- les scénarios où les mocks doivent suivre précisément des règles configurées.
La sortie Mock devrait maintenant être plus stable et plus proche de la configuration attendue.
🐞 Corrections de bugs et petites améliorations
Cette version inclut aussi plusieurs correctifs :
- Correction d’un problème où les paramètres de requête de la documentation partagée n’affichaient pas les exemples par défaut.
- Correction d’un problème où l’exportation d’un projet contenant seulement des documents Markdown, sans endpoints, pouvait échouer.
- Correction de plusieurs problèmes de génération de données Mock, y compris la génération par lots lorsque la génération JavaScript et la génération Mock étaient utilisées ensemble, les règles de multiplicateur numérique et les expressions
minetmaxdearrayElements. - Correction d’un problème où les liens fixes de la vue d’ensemble du projet pouvaient renvoyer une erreur 500 après l’ouverture de liens de différents projets en séquence.
- Correction d’un problème où l’interface pouvait afficher
Error: Cannot read properties of null (reading 'nullable')dans certains cas. - Correction d’un problème de contraste où les noms d’exemples sélectionnés dans la documentation partagée pouvaient être difficiles à lire en thème clair.
- Correction d’un problème où les utilisateurs Windows ne pouvaient pas utiliser normalement le débogueur d’agent IA.
- Correction d’un problème où un champ de corps
form-dataavec plusieurs fichiers téléchargés n’affichait qu’un seul fichier après l’ouverture et l’enregistrement de la modification par lots.
🌟 Ce que cela change pour votre workflow API
La version de mai vise à supprimer les petites frictions qui coûtent du temps dans les workflows API.
| Domaine | Ce qui s’améliore | Pourquoi c’est important |
|---|---|---|
| Migration Postman | Les URL de base partagées sont mappées lorsque Apidog peut les détecter de manière fiable. | Moins de nettoyage manuel après l’import de collections et la configuration des environnements. |
| Déploiement de Runner | Runner peut s’exécuter en tant qu’utilisateur non-root. | Meilleure compatibilité avec les politiques serveur, conteneur et CI/CD plus strictes. |
| Sécurité d’entreprise | Les Politiques d’entreprise commencent avec des contrôles de sécurité d’authentification. | Les administrateurs peuvent réduire l’exposition des identifiants bruts dans les workflows d’authentification. |
| Workflow Spec-First | Les projets Spec-First ne nécessitent plus de liaison Git avant utilisation. | Les équipes peuvent tester un travail centré sur OpenAPI avant de mettre en place un workflow de dépôt. |
| Partage de requêtes | Le code généré et les sorties cURL incluent davantage de configuration de la requête. | Les exemples sont plus faciles à exécuter, reproduire et partager. |
| Tests et Mocking | Les étapes de test se synchronisent plus précisément et la génération Mock est plus stable. | Les équipes passent moins de temps à corriger les dérives de configuration et les données de test inattendues. |
Aucune de ces mises à jour n’ajoute de complexité au workflow. Elles rendent surtout le travail après configuration moins fragile : moins de corrections manuelles, des valeurs par défaut plus sûres et des sorties plus proches de ce que vous avez déjà configuré.
💬 Rejoignez la conversation
Connectez-vous avec d’autres ingénieurs API et l’équipe Apidog :
- Rejoignez notre communauté Discord pour des discussions et du support en temps réel.
- Participez à notre communauté Slack pour des conversations techniques.
- Suivez-nous sur X/Twitter pour les dernières mises à jour.
P.S. Pour tous les détails sur les mises à jour, consultez le Journal des modifications d’Apidog.
Cordialement,
L’équipe Apidog
Top comments (0)