
280
| 第十章
雖然嚴格來說確實如此,但多數人都發現這種做法太難且沒價值,因而回去使用上述的
其中一種方法。因此,我們決定不在這本書中討論它,不過想要進一步研究的讀者可以
閱讀 Roy Fielding 的著作(
https://roy.gbiv.com
)。
在真正有需要時,才指定
API
版本
看完這一節之後,你可能會在每一個新端點(甚至既有的端點)前面加上
/v1
(或者,如果你選擇用內容類型來設定版本的話,改變所有端點的內
容類型)。事實上,即使你想要先做好處理 API 變動的準備,也不需要從
一開始就處理它們:如果你還要建立新服務以及做出許多決策,或許可以
延後處理版本,只要假設第 1 版代表“沒有版本”,等到(如果)你需要
處理變動時,再選擇版本系統。
多階段升級
前面的範例有服務在用戶端還沒有準備好使用新功能
之前
就提供了新功能,這意味著
你必須設法維持回溯相容性,無論是以回溯相容的方式進行變動,還是藉著建立新版的
API。你可能認為,如果你可以同時控制 API 的供應方與使用方的話,就可以繞過這種
麻煩,直接同時改變兩者,但是這種想法是錯的。
即使你可以同時改變兩者,也不保證變動可以在生產環境中同時生效。一方面,你的部
署策略可能會讓供應方的新舊版本的某段時間內,在生產環境中同時存在,如果你的用
戶端只能配合新版本,它就會在部署期間遇到嚴重的中斷。另一方面,你會在第 11 章
看到,你的變動需要經歷多個測試階段,或許那些測試對供應方而言是通過的,但是對
使用方而言不是如此(或反過來),也就是說,生產環境的供應方與使用方有版本不符 ...