ReST API에 대한 버전 관리 전략에 대해 읽어 봤는데 그중 어느 것도 기본 코드베이스를 관리하는 방법이 해결되지 않는 것 같습니다.
예를 들어, 단일 필드 대신 개별 forename및 surname필드를 반환하도록 고객 리소스를 변경하는 등 API에 많은 주요 변경 사항을 적용한다고 가정 해 보겠습니다 name. (이 예에서는 관련된 개념을 이해하기 쉽기 때문에 URL 버전 관리 솔루션을 사용하지만 질문은 콘텐츠 협상 또는 사용자 지정 HTTP 헤더에도 동일하게 적용됩니다.)
이제에 엔드 포인트가 http://api.mycompany.com/v1/customers/{id}있고에 호환되지 않는 다른 엔드 포인트가 http://api.mycompany.com/v2/customers/{id}있습니다. 우리는 여전히 v1 API에 대한 버그 수정 및 보안 업데이트를 릴리스하고 있지만 새로운 기능 개발은 이제 모두 v2에 초점을 맞추고 있습니다. API 서버에 변경 사항을 작성, 테스트 및 배포하는 방법은 무엇입니까? 적어도 두 가지 해결책을 볼 수 있습니다.
v1 코드베이스에 소스 제어 분기 / 태그를 사용합니다. v1 및 v2는 두 버전 모두에 동일한 버그 수정을 적용하는 데 필요한 개정 제어 병합을 사용하여 독립적으로 개발 및 배포됩니다. 이전 버전을 계속 지원하면서 주요 새 버전을 개발할 때 네이티브 앱의 코드베이스를 관리하는 방법과 유사합니다.
코드베이스 자체가 API 버전을 인식하도록하여 v1 고객 표현과 v2 고객 표현을 모두 포함하는 단일 코드베이스로 끝납니다. 배포 문제 대신 솔루션 아키텍처의 일부로 버전 관리를 처리하세요. 아마도 네임 스페이스와 라우팅의 일부 조합을 사용하여 요청이 올바른 버전에서 처리되는지 확인하세요.
브랜치 모델의 분명한 장점은 이전 API 버전을 삭제하는 것이 간단하다는 것입니다. 적절한 브랜치 / 태그 배포를 중지하면됩니다.하지만 여러 버전을 실행하는 경우 실제로 복잡한 브랜치 구조와 배포 파이프 라인이 될 수 있습니다. "통합 코드베이스"모델은이 문제를 피하지만 더 이상 필요하지 않은 코드베이스에서 더 이상 사용되지 않는 리소스와 엔드 포인트를 제거하기가 훨씬 더 어려워집니다. 간단한 정답이있을 것 같지 않기 때문에 이것이 아마도 주관적이라는 것을 알고 있지만 여러 버전에서 복잡한 API를 유지 관리하는 조직이이 문제를 해결하는 방법을 이해하고 싶습니다.