생산성을 높이는 POSTMAN 기능 활용. 2편

1편, API 인증 자동화로 API 호출을 좀 더 편하게 만들기.
2편, 콜렉션 수정내용 GIT 처럼 관리하기.
3편, API 호출 및 응답 예제를 작성해서 MOCK 서버 구축하기.
4편, 다양한 요청 포맷을 IMPORT/EXPORT.

2. 콜렉션 수정내용 GIT 처럼 관리하기.

1편에서, 포스트맨에서 Request를 묶는 최상위 단위는 Collection 이라고 말씀드렸었는데, 포스트맨은 Collection 이라는 단위를 다양하게 관리 활용 할 수 있도록 여러 기능을 제공하고 있습니다.

오늘은 여러 기능중에서도 Collection을 다른 사람과 공유하는 share 기능에 대해서 좀 더 상세 하게 알아보고, share 상황에서 어떻게 Collection을 공동 작업 할 수 있는지를 알아보겠습니다.

Collection share

본인이 작성한 Collection을 다른 사람에게 공유 할 수 있는 기능으로, 공유대상은 주로 Workspace 가 됩니다. 따라서, 해당 Workspace에 접근 가능한 사용자들은 공유된 Collection에 접근이 가능하고, Collection내에 존재 하는 Request를 실행 시켜 볼 수 있습니다. Collection 작성자는 손쉽게 다른 사람에게 공유할 수 있으니 자주 사용되는 기능중에 하나 입니다.

아래 방법을 통해 공유 할 수 있습니다.

1. 공유하고자 하는 Collection을 선택하여 share 메뉴로 진입.
2. share 할 대상 workspace 선택.

3. share 이후에 원본 Collection을 삭제 할것인지 | 그대로 둘것인지 선택.
   

4. share 될 Collection에 접근 가능한 사용자의 권한 설정.
   

Collection 공유 이후 작성자만 수정 업데이트를 하거나, 앞으로 수정 될 일이 아예 없다면 share기능으로 충분하지만, share이후에 Collection을 공유받은 다른 사람이 Collection을 수정 해야하는 상황이 오면, share만으로는 충분 하지 않을 수 있습니다.

Collection은 share 상태에서 어떤 워크스페이스에서 수정이 일어나건 저장을 하는 순간 모든 워크스페이스에 바로 적용이 됩니다. 이러한 사항 때문에 동시에 Collection을 여러 사용자가 사용하고 있는 상황이라면, 누구한명이 저장을 하는순간 다른 사용자는 영문도 모른채 수정된 Collection을 사용할 수 밖에 없습니다. 이를 위해 공동 작업에 용이한 Collection fork 기능을 포스트맨에서 제공하고 있습니다.

Collection fork

개발자들에게는 익숙한 용어인 fork 가 등장 했습니다. github에서도 자주 언급되고, OS의 process를 다룰 때도 언급이 되는 용어로, 복제하여 분기된 것이라는 의미로 자주 사용되는 용어입니다.
포스트맨에서도 fork 용어는 동일한 의미로 사용 되고 있습니다. Collection 을 fork 하면, 원본 Collection을 복제한 새로운 Collection을 생성하게 되고, fork된 Collection 가지고 자유롭게 수정을 할 수 있습니다. 이뿐이라면, Collection을 복사하는것과 다를바가 없는 기능이지만, fork된 Collection은 fork된 이후의 수정사항을 언제든 원본 Collection에 수정 내역만을 업데이트 시킬 수 있다는 것이 다릅니다.
위와같은 동작 덕분에, 여러사람들에게 공유된 Collection을 공동 수정 할 수 있게됩니다. 아래와 같은 예시 상황에서 fork 는 수정사항의 충돌을 해결 해줄 수 있습니다.

예시 상황

• 개발자 A,B는 공유된 동일한 Collection인 payment Collection에 존재하는 결제 조회 Request를 수정 하려 함.
• A의 수정 내용: 결제 조회 Request의 extension이라는 query parameter를 삭제 함.
• B의 수정 내용: 결제 조회 Request의 extension이라는 query parameter의 value값을 true 함.

share 상태에서의 결과.

share 상태라면 A,B가 저장한 시간순에 영향을 받습니다. A가 먼저 저장하고 B가 저장 했다면, A는 삭제 했음에도 extension query parameter가 다시 부활한 것으로 보여집니다.

fork 상태에서의 결과

A,B가 payment Collection을 각자 fork하여 payment-A, payment-B Collection 에서 수정 하고 저장한 뒤 원본 Collection인 payment에 수정 사항을 반영 하기 위해 각자 pull request 를 만듭니다.
payment-A의 pull request를 merge 하고, payment-B pull request를 merge 하려고 하면 conflict이 발생 했기 때문에 conflict를 해결하라는 알림이 뜨고, payment-B pull request는 거부 처리 합니다.
이렇게 되면, A의 수정 사항만 원본에 반영 되고 충돌은 해결 됩니다.

결론

공동 수정이 많은 컬렉션은 fork를 이용하여 수정 관리하자.
수정이 일어나지 않거나, 1명이 수정한다면 share를 이용하자