互聯(lián)網(wǎng)應(yīng)用架構(gòu)：專注編程教學，架構(gòu)，JAVA，Python，微服務(wù)，機器學習等領(lǐng)域，歡迎關(guān)注，一起學習。

對于API，在日常的工作中是接觸最多的東西，特別是我們軟件這一行，基本就是家常便飯了，在百度百科里面的解釋：

API（Application Programming Interface，應(yīng)用程序接口）是一些預(yù)先定義的函數(shù)，或指軟件系統(tǒng)不同組成部分銜接的約定。用來提供應(yīng)用程序與開發(fā)人員基于某軟件或硬件得以訪問的一組例程，而又無需訪問源碼，或理解內(nèi)部工作機制的細節(jié)。

在不同系統(tǒng)之間，不同部門之間的各種對接，API就是研發(fā)人員的一個純粹性的溝通語言，雙方定義好規(guī)范、約束等進行系統(tǒng)之間的交互。

生命周期

在我們軟件行業(yè)的領(lǐng)域里面，每一個軟件都是有生命周期的，從最開始的需求調(diào)研，需求設(shè)計，架構(gòu)設(shè)計，軟件研發(fā)，測試，上線，試運行，運行到最后業(yè)務(wù)上，技術(shù)上跟不上時代的發(fā)展，被新來的技術(shù)人員嫌棄，后面的業(yè)務(wù)部門拋棄，至此開始結(jié)束最后到下線，這個系統(tǒng)就算結(jié)束了他們的生命周期。

API是一種應(yīng)該性接口同樣具備了設(shè)計化、測試化的過程，這就顯性表明API其實也作為有生命周期的存在，在現(xiàn)有的設(shè)計中，API生命周期分為9種

設(shè)計
構(gòu)建/研發(fā)
管理
聯(lián)調(diào)/測試
自動化
文檔/發(fā)布
授權(quán)開放
監(jiān)控
下線

設(shè)計--見文知意

一個API的形成，設(shè)計是最根本的存在，因為他的存在不單單是自己使用，更重要的是讓多方可以使用，因此有一個規(guī)范的思想非常重要，這里有個方法論就是--見文知意。每次看到API都能知道這個API是做什么的，這是對開發(fā)者，使用者來說非常重要的一個方向，每一個API實際上對應(yīng)的一個后端服務(wù)的方法，必須有限定的出參與入?yún)?，其中出參與入?yún)⒈仨氂袊栏竦亩x。

入?yún)ⅲ河幸粋€重要的準則就是能快速進行參數(shù)的基礎(chǔ)屬性的校驗，例如是否為空，字段長度等，目前一般采用hibernate valid或者java自帶的valid來實現(xiàn)。

出參：出參的規(guī)范化體現(xiàn)在錯誤碼上，針對錯誤碼的定義需要非常明確，讓調(diào)用者可以一眼就能看到問題的所在，目前很多API接口在進行設(shè)計的時候一般只有正確與錯誤兩個錯誤碼，平時用著沒問題，在業(yè)務(wù)發(fā)展到一定程度后會增加運維的難度，建議錯誤碼按照不同的類別，例如業(yè)務(wù)、技術(shù)等區(qū)分。

構(gòu)建/研發(fā)--防范于未然

在進行了的第一步的規(guī)范化設(shè)計后，研發(fā)人員就要開始根據(jù)規(guī)范進行API接口的內(nèi)部業(yè)務(wù)邏輯的設(shè)計，具體的業(yè)務(wù)邏輯由業(yè)務(wù)邏輯來做限定，這里需要注意的就是非法參數(shù)盡可能排除的API之外，需要在入口處進行判斷并且匯集不合法的數(shù)據(jù)直接報錯，不允許出現(xiàn)在后續(xù)的業(yè)務(wù)代碼邏輯里面去判斷合法性，如上面所說采用hibernate valid進行操作，這些都是一個API生成的過程。

管理--運籌帷幄

每一個API的誕生到最后的下線它都是可控可管理的。

版本管理：每一個API從最開始發(fā)布到后面不斷迭代發(fā)布更新，都需要一個版本號來做限定，做到每一個版本可查可追溯。

文檔管理：API里面文檔是非常重要的存在，它是連接所有應(yīng)用的橋梁里面的中流砥柱，一份清晰可見的文檔是所有使用者的福報。在研發(fā)人員的世界中，最喜歡寫代碼，最痛苦寫文檔，但是如果把寫代碼變成一種寫代碼的方式呢，swagger可以幫你實現(xiàn)本地化文檔也可以實現(xiàn)離線文檔，還是直接導入到y(tǒng)api進行mock測試。

質(zhì)量審核：API并非寫完就完事，如果只是簡簡單單搞定并不按照規(guī)范走，入?yún)ap加上出參map的存在，那就要扯皮來，因此需要一個人來審核這些才能允許上線。

狀態(tài)碼管理：由于狀態(tài)碼是最常見的存在，因此它是微乎其微但是又是非常重要的東西，定義業(yè)務(wù)級別的狀態(tài)碼，定義系統(tǒng)級別的狀態(tài)碼，這些都需要進行管控起來。

迭代管理：迭代跟上面的版本有異曲同工之妙，版本更著重于版本號的定義及生成，迭代更側(cè)重于每一次迭代的跟進管理，等價于每一次的歷史記錄。

權(quán)限管理：API并非任何人都可以用的，需要進行授權(quán)。

服務(wù)管理：一個服務(wù)提供多個API，存在數(shù)據(jù)庫級別的1對N關(guān)系，需要這些進行分配及管理。

變更管理：API并非一成不變的，除了版本號的變更，經(jīng)常涉及到里面的內(nèi)容的管理，這些內(nèi)容需要做記錄及對比。

聯(lián)調(diào)/測試--微察秋毫

一個好的API除了規(guī)范設(shè)計清晰及業(yè)務(wù)邏輯清晰，更重要的是一定也是便于測試的，對應(yīng)的業(yè)務(wù)是否能完成，對應(yīng)的系統(tǒng)對接是否有足夠集成，是否提供了足夠的詳細的文檔，確保了API的質(zhì)量是有非常高的維護性的，這些通通在測試層進行驗證，本地化測試，MOCK測試，測試用例盡可能完整。

自動化--進退有度

相比于上面的人工測試，自動化測試是標準化的一種設(shè)計。按照約定設(shè)定好一定的標準閾值對接口進行測試，檢驗接口是否滿足我們最基礎(chǔ)的性能等要求，但是自動化測試并不是萬能的，何時介入，怎么介入，什么樣的項目適合自動化測試，這些都需要我們進行思考。

何時介入：在項目的剛開始的時候不適合自動測試的介入，業(yè)務(wù)穩(wěn)定性，需求變更快導致接口隨時隨地都在變化，代碼變動率非常高，維護成本非常高；到了后期后項目穩(wěn)定了項目進入維護階段，此時自動化開始介入并為回歸測試做好準備。

怎么介入：從自動化程度及自動化率來做切入點，雖然前期的項目并不適合做自動化測試，但是可以選用一些穩(wěn)定的，公用的進行測試。

適合項目：有意做回歸測試，并且需要長期做支持維護的項目；壓力測試的項目；覆蓋率測試的項目。

文檔/發(fā)布--十年磨一劍

這里用十年磨一劍有點夸張了，但是相對于開發(fā)者來說，每一個接口的誕生都是我都認為那是一項偉大的存在。在經(jīng)歷了前面的各種更改，測試，壓力考驗后可以正式發(fā)布了。每一個接口在發(fā)布后就直接跟網(wǎng)關(guān)對接，網(wǎng)關(guān)幫我們實現(xiàn)統(tǒng)一的鑒權(quán)，過濾，熔斷，限流等操作來保護我們每一個接口的安全。

授權(quán)開放--首肯心折

不是所有人都可以訪問API接口的，不是每個接口都是免費的，在必要的時刻需要我們對特定的接口做授權(quán)管理，規(guī)定哪些人可以訪問，哪些接口需要收費。

監(jiān)控--運籌帷幄

在API運行期間，最重要的也是最重點的工作就是對接口進行監(jiān)控，包括性能監(jiān)控、可用率監(jiān)控、調(diào)用量監(jiān)控等，并生成監(jiān)控報告。這些監(jiān)控都可以幫助我們從技術(shù)層面，業(yè)務(wù)層面進行分析接口的詳情情況及指標，確保每一個接口都盡可能實現(xiàn)價值，實現(xiàn)接口的性能達標跟可用率達標。

下線--功成名就

到了這里，接口基本上就是已經(jīng)功成名就完成它的使命，我們需要結(jié)束它的生命周期，有種莫名的傷感，夕陽西下，斷腸人在天涯，下線吧。

--END--

作者：@互聯(lián)網(wǎng)應(yīng)用架構(gòu)

原創(chuàng)作品，抄襲必究

如需要源碼或請轉(zhuǎn)發(fā)，關(guān)注后私信我

部分圖片或代碼來源網(wǎng)絡(luò)，如侵權(quán)請聯(lián)系刪除，謝謝！

總結(jié)

以上是生活随笔為你收集整理的微服务手册：API接口9个生命节点，构建全生命周期管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。