Rest API Backward compatibility 문의

Question

안녕하세요. Rest API를 유지하고 관리하는데 문의드립니다.보통 rest api가 업데이트되면 버젼닝을 붙여서v1, v2이런식으로 이전 버젼과 관리를합니다. 근데 이것은 전체적인 api 버젼관리이고, 만약 개발이 한창 이루어지는 상태에서 몇몇의 api는 잦은 업데이트로 그 몇몇의 api버젼만 올라간다면 이상하지 않을까해서요. 예를 들어 users/create란 api가 있고, users/create만 개발중 잦은 업데이트로 response와 전달 받는 파라메터들이 계속 변해서, 버젼이 v300이렇게 간다고 하면, /v300/users/create 이렇게 될것 같고, 나머지 api들은 v1이나 그렇게 될것 같습니다. 예를들어 /v1/users/update 생각하면 이렇게 한창 개발중에 잦은 업데이트로 인한 특정 api와 다른 api와의 버젼 불일치도 있고, 좀 이상하다고 생각이 됩니다. Rest API Backward compatibility를 위한 좋은 방법이 없을까요?

MungGaeDev · Answer

약간의 변경사항, 디버깅이라도 버전을 반드시 올리는 건 아닙니다.endpoint는 그대로 두고, 문서만 업데이트 하거나, 단순 디버깅이면 버전 변경없이 수정했다고 표시만 하거나 합니다.

mirheeoj · Answer

버그수정이 아닌 기능변화라면, 일반앱 API랑 비슷한 전략을 쓸 수 있을 걸로 봅니다. 기존 동작은 놔두고 새 인자를 도입해 그게 들어왔을때만 새 방식으로 동작하게 하든지, 기존 함수를 놔두고 새 함수를 도입한뒤 공통부분은 새 함수에서 기존 함수를 내부적으로 호출하든지 등등. 이러면 기존앱에는 영향이 안 가겠죠.만약 보안이나 버그 등 특별한 이유가 있어서 기존 동작을 아예 막아야 되면 클라이언트 수정은 불가피합니다. 이 경우는 클라이언트 자동 업데이트를 도입하든지, 아니면 무늬만 데탑앱이고 REST API관련부분은 웹기반으로 처리하게 만들든지 해야 되겠죠.

kiel · Answer

개발 도중에 버전이 계속 올라가는건 이상하네요. 클라이언트에 변경이 되었음을 공지할 정도에만 버전을 올리는게 좋을것 같습니다.각 end-point 는 모두 동일한 변경 주기를 가지지 않습니다. 만약 가져야 한다면 다같이 /v2/users/create 식으로 올리는게 맞고, 그렇지 않은 경우에는 각각 버전 올리면 됩니다. 이 경우 의미상으로는 /users/create/v1이 맞으나 보기에 좋지 않기 때문에 /v1/users/create 로 순서를 바꾼거라고 생각하시는게 좋을것 같습니다.요약 : 각각 버전 따로 올라가도 됩니다.

Rest API Backward compatibility 문의

3개의 답변

Q&A 목록