一、前言
一個專案中，隨著需求的變更或增加，API介面也會跟著變化，而如果專案發布后，已使用的介面肯定不能直接覆寫更新，需要新增升級版本介面和新的版本對應，因此多個版本介面更替后，如何更優雅管理不同版本介面代碼，如何設計更直觀的介面檔案呈現給前端，這是后端工程師需要考慮的事情，下面分享一些介面版本管理的經驗，
二、介面代碼版本規范
考慮到介面今后一定會進行版本迭代，因此一開始開發的時候，就需要對代碼進行版本考量下的代碼目標架構，
1. 控制器目錄架構
在controller下增加子集檔案夾：controller/v1/……、controller/v2/……等等，初始版本的介面全部放在v1下，
2. 介面路由設計
3. 不同版本控制器代碼分類依據
（1）在專案發布前的所有代碼，都屬于v1版本代碼；
（2）發布后，如果是新增加的需求，和已發布v1版本介面需求不沖突，新增控制器或介面，仍然屬于v1版本代碼；
（3）發布后，如果新增需求和v1已發布版本介面沖突，為了兼容老版本APP，必須在v2檔案夾下新增控制器開發v2版本介面，
遵循以上分類原則，依次遞推，嚴格區分不同版本介面代碼，結合下一部分的介面檔案，利于不同版本介面更新維護，
三、不同版本介面檔案規范和對比
版本迭代的介面，如果寫在一起，前端真的要瘋，最好能給前端一種重新開始的感覺，歸零后，面對新介面，溝通起來新老介面檔案區別明顯，這就大大避免了無謂的撕逼，具體介面檔案規范如下：
同時，有時候需要對比不同版本的介面資訊，我通常用的是Eolinker上的版本管理功能，可以清楚記錄并讓我看到各個版本的介面資訊對比，直接注冊就可以在網頁上用，貼在下面
www.eolinker.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/260895.html
標籤：其他
上一篇：【目標檢測】用Fast R-CNN訓練自己的資料集超詳細全程序
下一篇：API的主要趨勢