使用WSO2 API管理器進行版本控制服務URL

Question

我們最近開始使用WSO2 API管理器，我們希望對版本處理方面有所瞭解。有一個版本號是默認可用的，並且是強制性的。

Q1。我們可以改變這個嗎？還是必須使用它？ Q2302。只有在服務簽名發生變化時，版本纔會更改？即，我對服務進行後端更改，這不會改變Web服務中的公開方法。在這種情況下，我們是否更改版本號？或者只有當方法改變時我們才能改變它？

Q3。保持更改應用程序的服務URL不是很麻煩嗎？特別是如果這些服務用於移動應用程序？

希望您對此深入瞭解，以及當前實施中遵循的任何方法都是非常受歡迎的。謝謝！

Answer 1

答案1a。版本控制方案的格式不是強加給你的，但WSO2建議使用「version.major.minor」方法。在初始發佈期間，API版本控制可能不是必需的，或者甚至是不期望的，但是當需要撤銷錯誤的API或免費增值選項升級時，或者需要關鍵更新可用時，可能會節省一些情況。但恕我直言，這是最佳做法，首先。

答案1b。您必須使用某種版本方案來區分API的版本。

回答2.你如何參與你的版本實現的確是基於最適合你的DevOps團隊的。如果遵循version.major.minor方案，您在表示格式更改方面有很大的靈活性。查看維基百科的頁面[01​​]，有一些非常有用的升級示例，您的用戶一定會感謝您。對於我來說，提出一個版本控制方案是很困難的，因爲在版本控制方面不瞭解你的團隊文化，因爲每個團隊在偏好和實踐中都有差異。儘管如此，我會建議首先考慮用戶，最終用戶（應用程序開發人員）的利益比任何事情都要好，他們對糟糕的版本實現的失望可能是使用和陳舊之間的差異。應用程序開發人員和用戶希望儘可能多地進行版本控制，因爲他們期望升級和缺陷修復。我不相信不影響API的服務更改應該從純粹的功能角度導致API版本更新，但作爲應用程序開發人員，如果您更改了任何內容，我希望您對其進行版本化，因爲我想要由於即使是來自最完美的團隊也會出現的錯誤，或者在我自己的週期和最佳實踐中發生變化，因此您的「完美」變化具有回滾能力。我建議當你更新不改變功能的服務時，將它作爲一個小的+ 1改變發佈，並作爲升級選項提供給用戶，並允許現有的API功能不變（從端到端 - 結束）通過不貶值以及不需要重新認購。但是，當您更改方法或修復錯誤時，請分別將其作爲版本+1或主要+1推出，並且需要重新訂閱以確保清楚地說明更改和推薦的入門過程，並設置貶低過時或錯誤版本的日期。

回答3：在顛倒視角時，我相信您的用戶會更喜歡使用API​​作爲訂閱，端到端，並且他們希望升級任何發生在任何地方的任何和所有更改該API的服務。它既可以像上面提到的那樣進行入門以及回滾，也可以作爲專業人士對最佳實踐的期望。

最後，管理不滿意的用戶和糟糕的版本管理將會非常麻煩。您可能還需要設置計劃版本更改的時間表，以便您的開發人員意識到您的商店中有一個良好的持續改進計劃。