網際網路應用架構：專注程式設計教學，架構，JAVA，Python，微服務，機器學習等領域，歡迎關注，一起學習。
對於API，在日常的工作中是接觸最多的東西，特別是我們軟體這一行，基本就是家常便飯了，在百度百科裡面的解釋：
API（Application Programming Interface，應用程式介面）是一些預先定義的函式，或指軟體系統不同組成部分銜接的約定。 用來提供應用程式與開發人員基於某軟體或硬體得以訪問的一組例程，而又無需訪問原始碼，或理解內部工作機制的細節。
在不同系統之間，不同部門之間的各種對接，API就是研發人員的一個純粹性的溝通語言，雙方定義好規範、約束等進行系統之間的互動。
生命週期
在我們軟體行業的領域裡面，每一個軟體都是有生命週期的，從最開始的需求調研，需求設計，架構設計，軟體研發，測試，上線，試執行，執行到最後業務上，技術上跟不上時代的發展，被新來的技術人員嫌棄，後面的業務部門拋棄，至此開始結束最後到下線，這個系統就算結束了他們的生命週期。
API是一種應該性介面同樣具備了設計化、測試化的過程，這就顯性表明API其實也作為有生命週期的存在，在現有的設計中，API生命週期分為9種
- 設計
- 構建/研發
- 管理
- 聯調/測試
- 自動化
- 文件/釋出
- 授權開放
- 監控
- 下線
設計--見文知意
一個API的形成，設計是最根本的存在，因為他的存在不單單是自己使用，更重要的是讓多方可以使用，因此有一個規範的思想非常重要，這裡有個方法論就是--見文知意。每次看到API都能知道這個API是做什麼的，這是對開發者，使用者來說非常重要的一個方向，每一個API實際上對應的一個後端服務的方法，必須有限定的出參與入參，其中出參與入參必須有嚴格的定義。
入參：有一個重要的準則就是能快速進行引數的基礎屬性的校驗，例如是否為空，欄位長度等，目前一般採用hibernate valid或者java自帶的valid來實現。
出參：出參的規範化體現在錯誤碼上，針對錯誤碼的定義需要非常明確，讓呼叫者可以一眼就能看到問題的所在，目前很多API介面在進行設計的時候一般只有正確與錯誤兩個錯誤碼，平時用著沒問題，在業務發展到一定程度後會增加運維的難度，建議錯誤碼按照不同的類別，例如業務、技術等區分。
構建/研發--防範於未然
在進行了的第一步的規範化設計後，研發人員就要開始根據規範進行API介面的內部業務邏輯的設計，具體的業務邏輯由業務邏輯來做限定，這裡需要注意的就是非法引數儘可能排除的API之外，需要在入口處進行判斷並且彙集不合法的資料直接報錯，不允許出現在後續的業務程式碼邏輯裡面去判斷合法性，如上面所說採用hibernate valid進行操作，這些都是一個API生成的過程。
管理--運籌帷幄
每一個API的誕生到最後的下線它都是可控可管理的。
版本管理：每一個API從最開始釋出到後面不斷迭代釋出更新，都需要一個版本號來做限定，做到每一個版本可查可追溯。
文件管理：API裡面文件是非常重要的存在，它是連線所有應用的橋樑裡面的中流砥柱，一份清晰可見的文件是所有使用者的福報。在研發人員的世界中，最喜歡寫程式碼，最痛苦寫文件，但是如果把寫程式碼變成一種寫程式碼的方式呢，swagger可以幫你實現本地化文件也可以實現離線文件，還是直接匯入到yapi進行mock測試。
質量稽核：API並非寫完就完事，如果只是簡簡單單搞定並不按照規範走，入參map加上出參map的存在，那就要扯皮來，因此需要一個人來稽核這些才能允許上線。
狀態碼管理：由於狀態碼是最常見的存在，因此它是微乎其微但是又是非常重要的東西，定義業務級別的狀態碼，定義系統級別的狀態碼，這些都需要進行管控起來。
迭代管理：迭代跟上面的版本有異曲同工之妙，版本更著重於版本號的定義及生成，迭代更側重於每一次迭代的跟進管理，等價於每一次的歷史記錄。
許可權管理：API並非任何人都可以用的，需要進行授權。
服務管理：一個服務提供多個API，存在資料庫級別的1對N關係，需要這些進行分配及管理。
變更管理：API並非一成不變的，除了版本號的變更，經常涉及到裡面的內容的管理，這些內容需要做記錄及對比。
聯調/測試--微察秋毫
一個好的API除了規範設計清晰及業務邏輯清晰，更重要的是一定也是便於測試的，對應的業務是否能完成，對應的系統對接是否有足夠整合，是否提供了足夠的詳細的文件，確保了API的質量是有非常高的維護性的，這些通通在測試層進行驗證，本地化測試，MOCK測試，測試用例儘可能完整。
自動化--進退有度
相比於上面的人工測試，自動化測試是標準化的一種設計。按照約定設定好一定的標準閾值對介面進行測試，檢驗介面是否滿足我們最基礎的效能等要求，但是自動化測試並不是萬能的，何時介入，怎麼介入，什麼樣的專案適合自動化測試，這些都需要我們進行思考。
何時介入：在專案的剛開始的時候不適合自動測試的介入，業務穩定性，需求變更快導致介面隨時隨地都在變化，程式碼變動率非常高，維護成本非常高；到了後期後專案穩定了專案進入維護階段，此時自動化開始介入併為迴歸測試做好準備。
怎麼介入：從自動化程度及自動化率來做切入點，雖然前期的專案並不適合做自動化測試，但是可以選用一些穩定的，公用的進行測試。
適合專案：有意做迴歸測試，並且需要長期做支援維護的專案；壓力測試的專案；覆蓋率測試的專案。
文件/釋出--十年磨一劍
這裡用十年磨一劍有點誇張了，但是相對於開發者來說，每一個介面的誕生都是我都認為那是一項偉大的存在。在經歷了前面的各種更改，測試，壓力考驗後可以正式釋出了。每一個介面在釋出後就直接跟閘道器對接，閘道器幫我們實現統一的鑑權，過濾，熔斷，限流等操作來保護我們每一個介面的安全。
授權開放--首肯心折
不是所有人都可以訪問API介面的，不是每個介面都是免費的，在必要的時刻需要我們對特定的介面做授權管理，規定哪些人可以訪問，哪些介面需要收費。
監控--運籌帷幄
在API執行期間，最重要的也是最重點的工作就是對介面進行監控，包括效能監控、可用率監控、呼叫量監控等，並生成監控報告。這些監控都可以幫助我們從技術層面，業務層面進行分析介面的詳情情況及指標，確保每一個介面都儘可能實現價值，實現介面的效能達標跟可用率達標。
下線--功成名就
到了這裡，介面基本上就是已經功成名就完成它的使命，我們需要結束它的生命週期，有種莫名的傷感，夕陽西下，斷腸人在天涯，下線吧。
--END--
作者：@網際網路應用架構
原創作品，抄襲必究
如需要原始碼或請轉發，關注後私信我
部分圖片或程式碼來源網路，如侵權請聯絡刪除，謝謝！