從 Postman 遷移
1. 從 Postman 匯出
Section titled “1. 從 Postman 匯出”在 Postman 裡：Collection ▸ … ▸ Export ▸ Collection v2.1。環境也請照同樣的 方式匯出。
2. 匯入 Restorm
Section titled “2. 匯入 Restorm”檔案 ▸ 匯入（Ctrl+I），然後選擇那個 JSON 檔案。Restorm 會自己辨識格式。
細節：匯入 Postman 集合。
哪些會自動完成
Section titled “哪些會自動完成”| Postman | Restorm |
|---|---|
| 資料夾 | 資料夾，深度相同 |
| HTTP 請求 | HTTP 請求 |
| GraphQL 請求 | GraphQL 請求（而不是 HTTP 請求） |
| raw、formdata、urlencoded、file、graphql 內文 | 對應的內文類型 |
| 集合變數 | 某個環境的變數 |
| 描述 | 備註與 API 文件 |
| 範例回應 | API 文件 |
| pre-request 與 test 腳本 | 一個可執行的情境，搭配 pm.* 相容層 |
哪些需要手動調整
Section titled “哪些需要手動調整”Postman 的身分驗證區塊會被記錄成文件（敏感值會遮蔽），但不會被轉換成可執行 的憑證。
請重新建立一個身分驗證請求：這是五分鐘
的事，而且您換到的是權杖的自動更新，以及遇到 401 時的自動重試 — 這些 Postman
不會自己幫您做。
請從 Postman 匯出它們，然後在一個 環境資料夾裡重建。
不妨趁這個機會用上子環境：Postman 只能為每個目標各準備一個扁平的環境，而 Restorm 允許一個共用的基底，再依客戶或地區逐層覆寫。
runner 與 Newman
Section titled “runner 與 Newman”這是最划算的一次替換。一個情境能做到 runner 做的事，而且做得更好：
- 流程是看得見的，而不是集合裡一個隱含的順序；
- 分支、迴圈與重試都是一個個方塊，而不是
pm.setNextRequest； - 在 CI 中執行是內建的，結束代碼也很乾淨 — 請參閱 headless 執行與 CI。
| Postman | Restorm |
|---|---|
| Workspace | 一個 .restorm 專案，納入 git 版本控制 |
| Collection | 一個資料夾或一個環境資料夾 |
| Environment | 環境資料夾裡的一個環境 |
| Globals | 一個根環境，由它的子項繼承 |
| Pre-request / Test script | 一個情境，或一個程式碼動作 |
| Collection Runner | 一個情境 |
| Newman | restorm --run --headless |
| Mock Server | 本機的伺服器模式 |
| Monitors | 一個計時器動作，或您 CI 的一個排程工作 |
| Postman Console | 主控台 |
動態變數 {{$random…}} | 完全一樣，再加上 116 個 helper — 請參閱參考 |
您的請求會變成儲存庫裡的檔案。它們走的是和您程式碼一樣的審查流程，它們的 歷史就是 git 的歷史，存取權限就是您程式碼託管平台的權限。
沒有託管的工作區要管理，也沒有任何 API 資料落在第三方服務上。請參閱
.restorm 專案與檔案。
那些 Postman 有、而 Restorm 沒有的東西
Section titled “那些 Postman 有、而 Restorm 沒有的東西”老實說：Restorm 沒有託管的協作工作區、沒有公開的 API 入口網站、沒有直接掛在請求 上的留言，也沒有託管的監控。如果您的組織依賴這些東西，它們並沒有直接的對應物 — 分享一律走 git。