微服務 API 是服務與其客戶端之間的合約。 只有當您不中斷其 API 合約時，您才能獨立發展微服務，這就是為什麼合約如此重要的原因。 如果您變更合約，它會影響用戶端應用程式或 API 閘道。
API 定義的本質取決於您所使用的通訊協定。 例如，如果您使用傳訊，例如AMQP，API會包含訊息類型。 如果您使用 HTTP 和 RESTful 服務，API 包含 URL 和要求和回應 JSON 格式。
不過，即使您對初始合約有深思熟慮，服務 API 也需要隨著時間而變更。 發生這種情況時，特別是如果您的 API 是多個用戶端應用程式所取用的公用 API，您通常無法強制所有客戶端升級至新的 API 合約。 您通常需要逐步部署服務的新版本，使舊版本和新版本的服務可以同時執行。 因此，務必要有服務版本控制的策略。
當 API 的變更幅度很小時，例如將屬性或參數新增至 API，使用舊版 API 的客戶端應該切換並適應新版本的服務。 您可以針對任何必要的遺漏屬性提供預設值，而且用戶端可能會忽略任何額外的響應屬性。
不過，有時候您需要對服務 API 進行重大且不相容的變更。 因為您可能無法強制用戶端應用程式或服務立即升級至新版本，因此服務必須支援舊版 API 一段時間。 如果您使用 HTTP 型機制，例如 REST，其中一種方法是在 URL 或 HTTP 標頭中內嵌 API 版本號碼。 然後，您可以在相同的服務實例內同時實作這兩個服務版本，或部署每個處理 API 版本的不同實例。 這項功能的好方法是 Mediator 模式 （例如 MediatR 連結庫）將不同的實作版本分離為獨立處理程式。
最後，如果您使用 REST 架構， Hypermedia 是針對服務版本設定和允許可演進 API 的最佳解決方案。
其他資源
斯科特·漢塞爾曼 ASP.NET Core RESTful Web API 版本設定變得簡單
https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx建立 RESTful Web 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
