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의 인증 블록은 문서로 남지만(민감한 값은 가려집니다) 실행 가능한 인증 정보로 변환되지는 않습니다.
인증 요청을 새로 만드십시오. 5 분이면
되는 일이고, 그 대가로 토큰 자동 갱신과 401 재시도를 얻습니다. Postman은
이것을 스스로 해 주지 않습니다.
Postman에서 환경을 내보낸 뒤 변수 폴더 안에 다시 만드십시오.
이 기회에 하위 환경을 활용하십시오. Postman은 대상마다 평평한 환경 하나를 강요하지만, Restorm에서는 공통 기반을 두고 고객별 또는 지역별로 재정의할 수 있습니다.
러너와 Newman
Section titled “러너와 Newman”가장 이득이 큰 교체입니다. 시나리오는 러너가 하는 일을 더 잘 해냅니다.
- 흐름이 컬렉션의 암묵적 순서가 아니라 눈에 보이는 그림입니다.
- 분기, 루프, 재시도가
pm.setNextRequest가 아니라 박스입니다. - CI 실행이 내장되어 있고 종료 코드도 깔끔합니다 — 헤드리스 실행과 지속적 통합을 참고하십시오.
개념 대응표
Section titled “개념 대응표”| Postman | Restorm |
|---|---|
| Workspace | git으로 버전을 관리하는 .restorm 프로젝트 |
| 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을 통해 이루어집니다.