Migrera från Postman
1. Exportera från Postman
Section titled “1. Exportera från Postman”I Postman: Collection ▸ … ▸ Export ▸ Collection v2.1. Gör samma sak för dina miljöer.
2. Importera till Restorm
Section titled “2. Importera till Restorm”Arkiv ▸ Importera (Ctrl+I) och sedan JSON-filen. Restorm känner igen
formatet på egen hand.
Detaljer: Importera en Postman-samling.
Vad som går över automatiskt
Section titled “Vad som går över automatiskt”| Postman | Restorm |
|---|---|
| Mappar | Mappar, på samma djup |
| HTTP-begäranden | HTTP-begäranden |
| GraphQL-begäranden | GraphQL-begäranden (inte HTTP-begäranden) |
| Kropp av typen raw, formdata, urlencoded, file, graphql | Motsvarande kroppstyp |
| Samlingsvariabler | Variabler i en miljö |
| Beskrivningar | Anteckningar och API-dokumentation |
| Exempelsvar | API-dokumentation |
| Skript före begäran och tester | Ett körbart scenario, med skiktet pm.* |
Vad som kräver en justering
Section titled “Vad som kräver en justering”Autentiseringen
Section titled “Autentiseringen”Postmans autentiseringsblock dokumenteras (med känsliga värden maskerade) men omvandlas inte till körbara inloggningsuppgifter.
Skapa en autentiseringsbegäran på nytt:
det tar fem minuter, och du vinner automatisk förnyelse av token och nytt försök
vid 401, vilket Postman inte gör av sig självt.
Miljöerna
Section titled “Miljöerna”Exportera dem från Postman och skapa dem på nytt i en variabelmapp.
Passa på att använda undermiljöer: där Postman tvingar fram en platt miljö per mål låter Restorm dig ha en gemensam bas och överskrivningar per kund eller per region.
Runners och Newman
Section titled “Runners och Newman”Det är det mest lönsamma bytet. Ett scenario gör vad en runner gör, fast bättre:
- flödet är synligt i stället för att vara en underförstådd samlingsordning;
- förgreningar, loopar och nya försök är rutor, inte
pm.setNextRequest; - körningen i CI är inbyggd, med rena slutkoder — se Headless-körning och CI.
Motsvarigheter mellan begreppen
Section titled “Motsvarigheter mellan begreppen”| Postman | Restorm |
|---|---|
| Workspace | Ett projekt .restorm, versionshanterat i git |
| Collection | En mapp eller en variabelmapp |
| Environment | En miljö i en variabelmapp |
| Globals | En rotmiljö, som ärvs av dess barn |
| Pre-request / Test script | Ett scenario, eller en kodåtgärd |
| Collection Runner | Ett scenario |
| Newman | restorm --run --headless |
| Mock Server | Serverläget, lokalt |
| Monitors | En Timer-åtgärd, eller ett schemalagt jobb i din CI |
| Postman Console | Konsolen |
Dynamiska variabler {{$random…}} | Samma, plus 116 helpers — se referensen |
Den grundläggande skillnaden
Section titled “Den grundläggande skillnaden”Dina begäranden blir filer i ditt förvar. De följer samma granskningscykel som din kod, deras historik är git-historiken, och åtkomsträttigheterna är din kodhanterings.
Ingen hostad arbetsyta att administrera, och inga API-data hos en
tredjepartstjänst. Se
Projekt och .restorm-filer.
Och det som Postman har men inte Restorm
Section titled “Och det som Postman har men inte Restorm”För att vara ärliga: Restorm har ingen hostad samarbetsyta, ingen offentlig API-portal, inga inline-kommentarer på begäranden, och ingen hostad övervakning. Om din organisation lutar sig mot de sakerna finns det ingen direkt motsvarighet — delningen sker via git.