마이크로 서비스 API 및 계약 만들기, 발전 및 버전 관리

마이크로 서비스 API는 서비스와 해당 클라이언트 간의 계약입니다. API 계약을 중단하지 않는 경우에만 마이크로 서비스를 독립적으로 발전할 수 있으므로 계약이 매우 중요합니다. 계약을 변경하면 클라이언트 애플리케이션 또는 API 게이트웨이에 영향을 줍니다.

API 정의의 특성은 사용 중인 프로토콜에 따라 달라집니다. 예를 들어 AMQP와 같은 메시징을 사용하는 경우 API는 메시지 유형으로 구성됩니다. HTTP 및 RESTful 서비스를 사용하는 경우 API는 URL과 요청 및 응답 JSON 형식으로 구성됩니다.

그러나 초기 계약에 대해 신중하게 생각하더라도 서비스 API는 시간이 지남에 따라 변경해야 합니다. 이러한 경우, 특히 API가 여러 클라이언트 애플리케이션에서 사용하는 공용 API인 경우 일반적으로 모든 클라이언트가 새 API 계약으로 업그레이드하도록 강제할 수는 없습니다. 일반적으로 서비스 계약의 이전 버전과 새 버전이 동시에 실행되는 방식으로 새 버전의 서비스를 증분 방식으로 배포해야 합니다. 따라서 서비스 버전 관리 전략을 마련하는 것이 중요합니다.

API에 특성 또는 매개 변수를 추가하는 경우처럼 API 변경 내용이 작을 경우 이전 API를 사용하는 클라이언트는 새 버전의 서비스를 전환하고 작업해야 합니다. 필요한 누락된 특성에 대한 기본값을 제공할 수 있으며 클라이언트는 추가 응답 특성을 무시할 수 있습니다.

그러나 서비스 API에 대한 주요 변경 내용과 호환되지 않는 변경을 수행해야 하는 경우도 있습니다. 클라이언트 애플리케이션 또는 서비스가 새 버전으로 즉시 업그레이드되도록 강제할 수 없으므로 서비스는 특정 기간 동안 이전 버전의 API를 지원해야 합니다. REST와 같은 HTTP 기반 메커니즘을 사용하는 경우 한 가지 방법은 URL 또는 HTTP 헤더에 API 버전 번호를 포함하는 것입니다. 그런 다음 동일한 서비스 인스턴스 내에서 두 버전의 서비스를 동시에 구현하거나 각각 API 버전을 처리하는 다른 인스턴스를 배포할지 결정할 수 있습니다. 이 기능에 대한 좋은 방법은 다른 구현 버전을 독립 처리기로 분리하는 중재자 패턴 (예: MediatR 라이브러리)입니다.

마지막으로 REST 아키텍처를 사용하는 경우 Hypermedia 는 서비스 버전 관리를 위한 최상의 솔루션이며 진화 가능한 API를 허용합니다.

추가 리소스

• 스콧 핸셀먼. ASP.NET Core RESTful Web API 버전 관리가 용이해졌습니다.
  https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx

• RESTful 웹 API 버전 관리
  https://learn.microsoft.com/azure/architecture/best-practices/api-design#versioning-a-restful-web-api

• 로이 필딩. 버전 관리, 하이퍼미디어 및 REST
  https://www.infoq.com/articles/roy-fielding-on-versioning