Migrar do Postman
1. Exportar do Postman
Section titled “1. Exportar do Postman”No Postman: Collection ▸ … ▸ Export ▸ Collection v2.1. Faça o mesmo para os seus ambientes.
2. Importar no Restorm
Section titled “2. Importar no Restorm”Ficheiro ▸ Importar (Ctrl+I) e depois o ficheiro JSON. O Restorm deteta o
formato sozinho.
Detalhes: Importar uma coleção Postman.
O que passa automaticamente
Section titled “O que passa automaticamente”| Postman | Restorm |
|---|---|
| Pastas | Pastas, à mesma profundidade |
| Pedidos HTTP | Pedidos HTTP |
| Pedidos GraphQL | Pedidos GraphQL (não pedidos HTTP) |
| Corpos raw, formdata, urlencoded, file, graphql | O tipo de corpo correspondente |
| Variáveis de coleção | Variáveis de um ambiente |
| Descrições | Notas e documentação de API |
| Respostas de exemplo | Documentação de API |
| Scripts de pré-pedido e de teste | Um cenário executável, com a camada pm.* |
O que exige um ajuste
Section titled “O que exige um ajuste”A autenticação
Section titled “A autenticação”Os blocos de autenticação do Postman são documentados (valores sensíveis ocultados), mas não são convertidos em credenciais executáveis.
Recrie um pedido de autenticação: são
cinco minutos de trabalho, e ganha com isso a renovação automática do token e a
nova tentativa em caso de 401, o que o Postman não faz sozinho.
Os ambientes
Section titled “Os ambientes”Exporte-os do Postman e recrie-os numa pasta de variáveis.
Aproveite para usar os subambientes: onde o Postman impõe um ambiente plano por alvo, o Restorm permite uma base comum e substituições por cliente ou por região.
Os runners e o Newman
Section titled “Os runners e o Newman”É a substituição mais rentável. Um cenário faz o que um runner faz, mas melhor:
- o fluxo é visível em vez de ser uma ordem de coleção implícita;
- as ramificações, os ciclos e as novas tentativas são caixas, não
pm.setNextRequest; - a execução em CI é integrada, com códigos de saída limpos — consulte Execução headless e CI.
Equivalências de conceitos
Section titled “Equivalências de conceitos”| Postman | Restorm |
|---|---|
| Workspace | Um projeto .restorm, versionado no git |
| Collection | Uma pasta ou uma pasta de variáveis |
| Environment | Um ambiente numa pasta de variáveis |
| Globals | Um ambiente de raiz, herdado pelos seus descendentes |
| Pre-request / Test script | Um cenário, ou uma ação de código |
| Collection Runner | Um cenário |
| Newman | restorm --run --headless |
| Mock Server | O modo servidor, em local |
| Monitors | Uma ação Temporizador, ou uma tarefa agendada da sua CI |
| Postman Console | A consola |
Variáveis dinâmicas {{$random…}} | As mesmas, mais 116 helpers — consulte a referência |
A diferença de fundo
Section titled “A diferença de fundo”Os seus pedidos passam a ser ficheiros no seu repositório. Seguem o mesmo ciclo de revisão que o seu código, o seu histórico é o histórico git e os direitos de acesso são os da sua plataforma git.
Nenhuma área de trabalho alojada para administrar, e nenhum dado de API num
serviço externo. Consulte
Projetos e ficheiros .restorm.
E o que o Postman tem e o Restorm não tem
Section titled “E o que o Postman tem e o Restorm não tem”Para ser honesto: o Restorm não tem área de trabalho colaborativa alojada, nem portal de API público, nem comentários em linha nos pedidos, nem monitorização alojada. Se a sua organização se apoia nestes elementos, eles não têm equivalente direto — a partilha passa pelo git.