Migrer depuis Postman
1. Exporter depuis Postman
Section titled “1. Exporter depuis Postman”Dans Postman : Collection ▸ … ▸ Export ▸ Collection v2.1. Faites de même pour vos environnements.
2. Importer dans Restorm
Section titled “2. Importer dans Restorm”Fichier ▸ Importer (Ctrl+I) puis le fichier JSON. Restorm détecte le
format seul.
Détails : Importer une collection Postman.
Ce qui passe automatiquement
Section titled “Ce qui passe automatiquement”| Postman | Restorm |
|---|---|
| Dossiers | Dossiers, à la même profondeur |
| Requêtes HTTP | Requêtes HTTP |
| Requêtes GraphQL | Requêtes GraphQL (pas des requêtes HTTP) |
| Corps raw, formdata, urlencoded, file, graphql | Le type de corps correspondant |
| Variables de collection | Variables d’un environnement |
| Descriptions | Notes et documentation d’API |
| Réponses d’exemple | Documentation d’API |
| Scripts pré-requête et tests | Un scénario exécutable, avec la couche pm.* |
Ce qui demande un ajustement
Section titled “Ce qui demande un ajustement”L’authentification
Section titled “L’authentification”Les blocs d’authentification Postman sont documentés (valeurs sensibles masquées) mais pas convertis en identifiants exécutables.
Recréez une requête d’authentification : c’est
l’affaire de cinq minutes, et vous y gagnez le renouvellement automatique du
jeton et le réessai sur 401, que Postman ne fait pas tout seul.
Les environnements
Section titled “Les environnements”Exportez-les depuis Postman et recréez-les dans un dossier de variables.
Profitez-en pour utiliser les sous-environnements : là où Postman impose un environnement plat par cible, Restorm permet une base commune et des surcharges par client ou par région.
Les runners et Newman
Section titled “Les runners et Newman”C’est le remplacement le plus rentable. Un scénario fait ce que fait un runner, en mieux :
- le flux est visible au lieu d’être un ordre de collection implicite ;
- les branchements, boucles et réessais sont des boîtes, pas du
pm.setNextRequest; - l’exécution en CI est intégrée, avec des codes de sortie propres — voir Exécution headless et CI.
Équivalences de concepts
Section titled “Équivalences de concepts”| Postman | Restorm |
|---|---|
| Workspace | Un projet .restorm, versionné dans git |
| Collection | Un dossier ou un dossier de variables |
| Environment | Un environnement dans un dossier de variables |
| Globals | Un environnement racine, hérité par ses enfants |
| Pre-request / Test script | Un scénario, ou une action de code |
| Collection Runner | Un scénario |
| Newman | restorm --run --headless |
| Mock Server | Le mode serveur, en local |
| Monitors | Une action Minuteur, ou une tâche planifiée de votre CI |
| Postman Console | La console |
Variables dynamiques {{$random…}} | Les mêmes, plus 116 helpers — voir la référence |
La différence de fond
Section titled “La différence de fond”Vos requêtes deviennent des fichiers dans votre dépôt. Elles suivent le même cycle de revue que votre code, leur historique est l’historique git, et les droits d’accès sont ceux de votre forge.
Aucun espace de travail hébergé à administrer, et aucune donnée d’API sur un
service tiers. Voir
Projets et fichiers .restorm.
Et ce que Postman a que Restorm n’a pas
Section titled “Et ce que Postman a que Restorm n’a pas”Pour être honnête : Restorm n’a pas d’espace de travail collaboratif hébergé, pas de portail d’API public, pas de commentaires en ligne sur les requêtes, et pas de monitoring hébergé. Si votre organisation s’appuie sur ces éléments, ils n’ont pas d’équivalent direct — le partage passe par git.