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

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

3. API 호출 및 응답 예제를 작성해서 MOCK 서버 구축하기.

오늘은 포스트맨의 기능중에서 MOCK API서버를 손쉽게 구축하는 방법에 대해서 알아보려고 합니다.

기능개발을 하다보면, API를 사용하는 입장인 클라이언트와 동시에 개발을 진행하게 되는 상황이 자주 발생하게 됩니다. 기능 설계 단계에서 서로 어떻게 데이터를 주고 받을지에 대한 API 인터페이스 정의를 내리고 나면, 클라이언트 개발자와 백엔드 개발자는 각자 정의된 인터페이스에 맞춰서 기능 개발에 돌입합니다. 클라이언트 개발자들은 개발중에 인터페이스를 호출하는 코드를 작성하고 나면 동작 테스트를 위해, 실제 테스트를 해보아야하는데 백엔드 API개발이 완료되지 않은 상태에서는 개발 완료될 때 까지 어쩔 수 없이 기다리게 됩니다.

이런 상황을 해소헤 줄 수 있는 것이 MOCK API 서버 입니다. MOCK API 서버는 백엔드 코드를 실행하지 않고, 준비된 고정 응답을 내려보내 줄 수 있는 간단한 서버로 제공됩니다. 위 상황에서 인터페이스 정의가 완료된 상태라면, 어떤 응답이 실제로 내려가게 될지 예시를 충분히 작성 해볼 수 있고, 몇몇 예시를 만들어서 API호출시 고정된 응답으로 보내줄 수가 있게 됩니다.

포스트맨은 하나의 요청에 대해 여러 예시를 추가 할 수 있도록 기능이 마련되어 있고, 이렇게 작성해 둔 예시는 개발자가 API를 더 잘 이해 할 수 있게 만들어줍니다. 거기에 더해 포스트맨에서는 작성된 예시를 실제로 응답해 줄 수 있는 MOCK API 서버를 아주 간단하게 만들어주는 기능을 제공하고 있습니다.

예제

MOCK API 서버를 만드는 간단한 과정을 예시와 함께 보여 드리겠습니다.
아래와 같이 API 인터페이스가 정의되어 있는 상태라면 포스트맨에 컬렉션과 컬렉션내에 요청 하나를 만들 수 있습니다.

REDOC 문서

OpenAPI 3.0 정의

openapi: '3.0.2'
info:
  title: 블로그 API
  version: '1.0'
paths:
  /post/{post_id}:
    get:
      description: 블로그 상세 조회 API
      parameters:
        - in: path
          name: post_id
          required: true
          schema:
            type: number
            example: 1
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: number
                    example: 1
                  title:
                    type: string
                    example: 첫번쨰 포스트
                  content:
                    type: string
                    example: '<p>안녕하세요 첫번쨰 <b>포스트</b> 입니다.</p>'                  
        '404':
          description: Not found

위 API 문서 YAML를 포스트맨에 임포트 시켜서 만드는 방법도 있지만 일단 여기서는 직접 만들어 낸 요청을 보여드리겠습니다.

위 화면을 보시면 Blog examples 컬렉션이 만들어진것이 보이고 Get post detail 이라는 이름의 요청을 하나 만든것을 보실 수 있습니다. 아직은 개발 된 API가 아니므로 요청을 실행해도 응답 받을 수가 없습니다.

아래 순서로 작업하여, MOCK 서버를 완성 해보겠습니다.

1. 요청의 example을 응답 종류 만큼 생성 합니다.
2. API내의 모든 example 이 작성완료 되면, mock 서버를 생성합니다.
3. 만들어진 mock 서버의 url을 host에 넣어 요청 해보고 example에 정의했던 응답이 오는지 확인합니다.

1. 요청의 example을 응답 종류 만큼 생성 합니다.

API 인터페이스 정의를 보면 API 호출시 응답 상태값 200과 404응답이 될 수 있습니다. MOCK 서버가 동일하게 200응답 404응답을 내려줄수 있도록 하려면 200과 404 각각 example을 만들어 주어야 합니다. 이때 주의 할 점은 example 에 요청 부분을 각각 다르게 지정해야, 요청에 맞게 MOCK서버가 다르게 응답할 수 있게 됩니다.

아래 예시에서는 post_id값이 1로 요청되는 경우 200 OK가 응답 되도록, post_id값이 2로 요청되는 경우는 404 Not found가 응답 되도록 example을 작성하였습니다.

200 example

404 example

2. API내의 모든 example 이 작성완료 되면, mock 서버를 생성합니다.

컬렉션 편집 메뉴 중에서 mock collection 을 선택합니다. 생성시 몇몇 설정 값을 입력하고 생성버튼을 클릭합니다.

• Make mock server private 설정의 경우는 MOCK 서버에 API-KEY헤더를 넣어야 응답이 되는 수 있는 프라이빗 사용설정 입니다.
• Simulate fixed network delay 설정은 MOCK서버의 네트워크 속도를 시뮬레이션 할 수 있는 옵션입니다. MOCK 서버가 응답시 특정 딜레이 경과 후 응답하게 됩니다.

3. 만들어진 MOCK 서버의 URL을 HOST에 넣어 요청 해보고 example에 정의했던 응답이 오는지 확인합니다.

post_id:1 요청시 200 응답

post_id:2 요청시 404 응답

자 이제 클라이언트 개발자분들께 인터페이스 정의가 끝나고 바로 "호출해 보실 수 있습니다." 라고 당당하게 말할 수 있게 되었습니다.