API向後兼容性的最佳實踐

我正在研究與JSON API通信的iPhone/iPad/Android應用程序。API向後兼容性的最佳實踐

該應用程序版本的第一個版本已完成，現在正在進行其他開發階段。在其他階段，應用程序需要與API的新版本集成，並允許用戶訪問其他功能，例如新屏幕或在現有屏幕中修改的行爲。然而，該應用程序需要與之前版本的API相反。

解決此類需求的最佳做法是什麼？我的可在全代碼做的檢查：

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

} else if (APIVersion == ....) { 

}...

但我很擔心這種方法的可擴展性。工廠的方法讓人想起，但我不知道這會讓我感覺有多遠。

謝謝，馬克

來源

2012-05-23 Mark

的一個新的API版本發佈是一個非常罕見的事情。通常，只需添加新的可選參數或新方法即可實現向後兼容。舉例來說，如果你有方法命名爲search，但現在你不滿意它的工作方式，你可以通過各種方式對付它：

如果變化是簡單的，你可以添加一個新的mode參數，默認爲mode1（所以它是向後兼容的）。如果用戶提供mode2，則可以使用正確的if條件檢測它，正如您自己提出的那樣。（另外，通常你可以想到比「模式」更好的名字）。
如果變化很大，你可以添加一個新的使用新接口的search2服務。然後，您將search方法標記爲已棄用（但仍可正常工作並向後兼容）。通常當你這樣做時，你可以用這樣的方式重構你的代碼，幾乎所有的邏輯都在search2方法中，而你的舊search方法在內部調用search2修改過的參數（並且適當地重新格式化結果）。如果你正確地做到這一點，你將不再需要改變search方法。當你改變你的桌子等 - 你只需要修改search2。

我的觀點是，避免發佈N+1-API版本。這樣的大版本意味着您的方法的ALL的重大變化，而不僅僅是一個。許多主要API從未發佈其API的第2版，它們仍然使用版本1，只是略微修改了其中的一部分，如上例所示。

如果絕對的把握約釋放你的API N+1 -st版本，ALL的你的方法創建新的切入點。如果您有一個名爲services的文件夾，請創建一個名爲services-v2的新文件夾。重構您的services代碼，以便它使用最多services-v2。如果您認爲它過度殺毒，那麼我認爲您不需要N+1-API版本。

順便說一句，不要將集中的API（如Google地圖）與分佈式API（如Android）混淆。 Android始終發佈新的API版本，因爲有數十億臺Android服務器（每臺Android設備都是一臺），而且它們都不能簡單地由Google遠程升級。 Android的下一個版本仍然與前一版本向後兼容，增加的數字僅表示新功能。例如您仍然可以在Android 7.0上運行鍼對Android 3.0構建的應用程序（用戶可能會收到一些額外的警告，但應用程序將運行）。 Android應用程序開發人員使用這些數字來描述其應用程序的「最低要求」。 而集中式API通常會增加其版本號以指示主要的向後不兼容變更。

來源

2012-05-23 09:30:44 wrygiel

謝謝。我採用了第一項重點建議。這些變化相當小，所以我設法執行API版本條件檢查，並且擴展具有不同可選參數的方法，或者在某些情況下爲每個API版本創建新方法。 API版本超出了我的控制範圍，因爲它是客戶端API。 – Mark

這是一個非常好的答案，我希望我也能得到一些鏈接和指針。 – Alex

我想你已經有了關注點分離。我的意思是，只有通過模型（例如）獲取應用程序的數據。

所以你只需要改變模型。

我的建議是，只有一個入口點：「路由器」文件。該文件檢查所需的API版本，並加載正確的文件。這樣，您爲每個API獲取不同的文件。「路由器」文件不會很大，每個新的API版本都會有自己的文件，所以你不會混淆一切。

例如，在「路由器」文件：

function dispatch() { 
    switch (APIVersion) { 
    case 1: 
     use('file.1.ext'); 
     break; 
    case 2: 
     use('file.2.ext'); 
     break; 
    case 3: 
     use('file.3.ext'); 
     break; 
    } 
}

來源

2012-05-23 09:18:15

API向後兼容性的最佳實踐

回答

相關問題