从 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 文档 |
| 前置请求脚本与测试脚本 | 一个可执行的场景，配合 pm.* 兼容层 |
哪些需要调整
Section titled “哪些需要调整”Postman 的身份验证配置块会被记录为文档（敏感值经过遮蔽），但不会转换成可执行的凭据。
请重新创建一个身份验证请求：这只需五分钟，
而且您还能获得令牌的自动续期以及 401 时的自动重试 —— 这些 Postman 并不会自动完成。
从 Postman 导出它们，然后在一个 变量文件夹中重新创建。
不妨借此机会使用子环境：Postman 要求每个目标对应一个扁平的环境， 而 Restorm 允许有一个公共基础，再按客户或按地区进行覆盖。
运行器与 Newman
Section titled “运行器与 Newman”这是回报最高的一项替换。一个 场景能做到运行器所做的事，而且做得更好：
- 数据流是可见的，而不是隐含在集合顺序里；
- 分支、循环和重试都是一个个方块，而不是
pm.setNextRequest； - CI 执行是内建能力，并带有清晰的退出码 —— 请参阅 headless 执行与 CI。
概念对应关系
Section titled “概念对应关系”| 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 个辅助函数 —— 请参阅参考 |
根本上的差别
Section titled “根本上的差别”您的请求会变成您仓库中的文件。它们遵循与代码相同的评审流程，它们的历史就是 git 历史，访问权限就是您代码托管平台上的权限。
没有托管的工作空间需要管理，也没有任何 API 数据留在第三方服务上。请参阅
项目与 .restorm 文件。
以及 Postman 有而 Restorm 没有的东西
Section titled “以及 Postman 有而 Restorm 没有的东西”说句实话：Restorm 没有托管的协作工作空间，没有公共 API 门户， 没有针对请求的行内评论，也没有托管的监控。如果您的组织依赖这些能力， 它们没有直接的对应物 —— 共享通过 git 进行。