網際網路應用架構：專注編程教學，架構，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--
作者：@網際網路應用架構
原創作品，抄襲必究
如需要源碼或請轉發，關注後私信我
部分圖片或代碼來源網絡，如侵權請聯繫刪除，謝謝！