티스토리 뷰

API를 개발하다보면 API의 버전을 나눌 필요가 있다.


그런데 API가 바뀔 때가 아니더라도 UI나 아이콘과 같은 것들이 바뀔 때 클라이언트의 버전은 올라가야한다.


그래서 버전을 구분하는 것을 API Level과 Version으로 나누도록 한다.


  • API Level: API가 추가되거나 값이 바뀔때 올라가도록 함
  • Version: API가 변경되지 않더라도 다른 무언가가 바뀌었을 때 올라가도록 함
따라서 일정 API Level에 따라 URI에 클라이언트의 버전을 path를 추가하는 방식을 사용한다.

AP 서버를 운영하다보면 웹 서버 엔진을 사용하게 되는데, 나는 nginx를 사용하였기에 nginx를 통해서 API versioning을 해보았다.

nginx에서 http request의 header를 변수로 가져올 수 있기에 nginx의 $http_header 변수로 API Level을 보내도록 한다.

현재 상황은 django를 통해서 AP 서버가 띄워져있는 상태이고, 
아래는 /etc/nginx/sites-available내의 도메인 config이다.

    server_name mydomain.com;

    location / {
        include proxy_params;
        proxy_pass http://127.0.0.1:45654;
    }
}

클라이언트의 버전이 v1, v2가 있다고 봤을 때


    server_name mydomain.com;

    if ($http_apilevel = 1) {
        rewrite ^/(.*)$ /v1/$1?${args}? break;
    }

    if ($http_apilevel = 2) {
        rewrite ^/(.*)$ /v2/$1?${args}? break;
    }

    location / {
        include proxy_params;
        proxy_pass http://127.0.0.1:45654;
    }

}

위와 같이 nginx 설정을 변경한 후, nginx를 재시작해준다.


그리고 postman으로 api를 테스트해보면,


위와 같이 다른 api 결과가 나오게 된다.


http header에 apilevel을 1로 하면

http://mydomain.com/test로 request를 보내게 되면,

nginx에서 url을 rewrite해서 API 서버에 보내지게 된다.


/test    -> /v1/test      # apilevel을 1로 보냈을 때

/test    -> /v2/test      # apilevel을 2로 보냈을 때



물론 위와 같이 API를 버저닝하려면 

API 서버단에서 버전에 따라 다른 API 로직을 타도록 해야한다.


현재 django로 API 서버를 구현하였고, 아래와 같이 API 버전을 나누었다.


django의 url 설정


django의 API가 들어오는 view 구현





이렇게 되면 버전이 다른 클라이언트들에서도 API 호스트는 똑같이 http://mydomain.com/test로 접근하면 된다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함