Migrare da Postman
1. Esportare da Postman
Section titled “1. Esportare da Postman”In Postman: Collection ▸ … ▸ Export ▸ Collection v2.1. Occorre fare lo stesso per gli ambienti.
2. Importare in Restorm
Section titled “2. Importare in Restorm”File ▸ Importa (Ctrl+I) e poi il file JSON. Restorm rileva il
formato da solo.
Dettagli: Importare una collezione Postman.
Ciò che passa automaticamente
Section titled “Ciò che passa automaticamente”| Postman | Restorm |
|---|---|
| Cartelle | Cartelle, alla stessa profondità |
| Richieste HTTP | Richieste HTTP |
| Richieste GraphQL | Richieste GraphQL (non richieste HTTP) |
| Corpi raw, formdata, urlencoded, file, graphql | Il tipo di corpo corrispondente |
| Variabili di collezione | Variabili di un ambiente |
| Descrizioni | Note e documentazione di API |
| Risposte di esempio | Documentazione di API |
| Script di pre-richiesta e test | Uno scenario eseguibile, con il livello pm.* |
Ciò che richiede un aggiustamento
Section titled “Ciò che richiede un aggiustamento”L’autenticazione
Section titled “L’autenticazione”I blocchi di autenticazione di Postman vengono documentati (valori sensibili mascherati) ma non convertiti in credenziali eseguibili.
Occorre ricreare una richiesta di autenticazione:
è questione di cinque minuti, e in cambio si ottiene il rinnovo automatico del
token e il nuovo tentativo su 401, cosa che Postman non fa da solo.
Gli ambienti
Section titled “Gli ambienti”Vanno esportati da Postman e ricreati in una cartella di variabili.
Vale la pena approfittarne per usare i sotto-ambienti: là dove Postman impone un ambiente piatto per destinazione, Restorm permette una base comune e sovrascritture per cliente o per regione.
I runner e Newman
Section titled “I runner e Newman”È la sostituzione più redditizia. Uno scenario fa ciò che fa un runner, ma meglio:
- il flusso è visibile invece di essere un ordine di collezione implicito;
- diramazioni, cicli e nuovi tentativi sono riquadri, non
pm.setNextRequest; - l’esecuzione in CI è integrata, con codici di uscita puliti — si veda Esecuzione headless e CI.
Equivalenze di concetti
Section titled “Equivalenze di concetti”| Postman | Restorm |
|---|---|
| Workspace | Un progetto .restorm, versionato in git |
| Collection | Una cartella o una cartella di variabili |
| Environment | Un ambiente in una cartella di variabili |
| Globals | Un ambiente radice, ereditato dai suoi figli |
| Pre-request / Test script | Uno scenario, o un’azione di codice |
| Collection Runner | Uno scenario |
| Newman | restorm --run --headless |
| Mock Server | La modalità server, in locale |
| Monitors | Un’azione Timer, o un’attività pianificata della propria CI |
| Postman Console | La console |
Variabili dinamiche {{$random…}} | Le stesse, più 116 helper — si veda il riferimento |
La differenza di fondo
Section titled “La differenza di fondo”Le richieste diventano file nel proprio repository. Seguono lo stesso ciclo di revisione del codice, la loro cronologia è la cronologia git e i diritti di accesso sono quelli della propria forge.
Nessuno spazio di lavoro ospitato da amministrare, e nessun dato di API su un
servizio di terze parti. Si veda
Progetti e file .restorm.
E ciò che Postman ha e Restorm non ha
Section titled “E ciò che Postman ha e Restorm non ha”Per essere onesti: Restorm non ha uno spazio di lavoro collaborativo ospitato, né un portale di API pubblico, né commenti inline sulle richieste, né monitoraggio ospitato. Se un’organizzazione si appoggia a questi elementi, non hanno un equivalente diretto — la condivisione passa da git.