據??行業分析機構451 Group指出??，目前企業擁有的 API 的平均數量超過15,000個。顯然，這一數字遠高于??平臺運營??團隊可以用電子表格跟蹤的API 的平均數量。即使將API跟蹤的責任分配給各個業務部門，考慮到API數量的驚人的增長速度，這仍然是一項艱巨的任務。

2021年，F5工程師和技術專家Rajesh Narayanan為這個問題創造了一個新詞：??API蔓延??（API sprawl）。“API蔓延”一詞的含義正如其名——即世界各地的企業中的API數量的加速增長，而這也給API的管理和防護帶來了巨大挑戰。這一問題有多嚴重？據Narayan估計，到2030年，全球部署和運行的API將超過10億個。

現代應用在開發方式方面的變化加速了API的蔓延。微服務的興起、用于系統內部通信的API的不斷增加，以及多云和混合云架構的快速增加，都使得我們需要更多地使用API在應用之間進行通信。例如，作為容器編排的事實標準的Kubernetes就是使用API來實現所有的內部通信的。新的基礎架構類型（如serverless架構）也意味著API可以在幾乎所有環境中運行。同時還有更多種類的API技術需要管理——REST、GraphQL和gRPC都已被廣泛使用，而更多的API查詢協議也將很快出現。

更糟糕的是，網絡罪犯絕對會樂于見到API蔓延。他們越來越多地將API作為他們精確攻擊的目標，原因是API通常沒有得到仔細的管理，而且默認配置的訪問權限相對開放。

為了消除這種問題，必須以程序化、規模化的解決方案來應對API管理、發現和防護方面的挑戰。不過在您能夠??有效應對API蔓延??之前，您需要先了解該問題在您的組織機構中的嚴重程度。以下六個明顯跡象表明您遇到了API蔓延問題。

1. 沒有最近更新的API清單

API蔓延的典型癥狀是不知道在所有環境中都運行著哪些API，這通常是由于松散的API管理策略導致的——在這種策略下，團隊無需注冊僅在內部使用的API（即所謂的“影子API”）。

您的首要任務是準確盤點現有的API。但由于API的添加和棄用通常極為頻繁，想要“準確盤點”就需要不斷地進行統計。合理的解決方案是通過編程式的方式進行盤點并持續進行API發現，類似于網絡掃描和資產發現。

從理論上講，結構化的API審批流程也有所助益。但在現實中，對于API創建和版本管理等任務，不斷“左移”的企業會想要縮減繁重的審批流程。對于這些企業來說，將API清單盤點作為CI/CD的一部分來構建流程通常是一種很好的方法，尤其是當API用于微服務和其他更現代的應用架構時。

2. 不知道每個API分別在何處運行

在現代基礎架構環境中，僅僅知道API的存在還遠遠不夠——還需要知道每個API的位置。端點可能會在不同基礎架構形式的容器間互為鏡像——橫跨多個云平臺、在混合云中，或者在像是 serverless 這樣的多種服務中。

安全團隊需要掌握API的位置信息，從而正確配置策略和防護措施并運行API安全測試。如果您需要在多個環境中運行API，這也會影響您對于??API網關??和其他API流量管理方式的選擇。理想情況下，您會希望有一個適用全局的API網關解決方案，以便能夠在不同環境中實現具有一致性的API流量管理和防護。

3. 無法輕松地識別API的所有者或負責人 如果您不知道API由誰負責，當API出現問題時，就不知道該找誰處理。通常情況下，當構建API的人或團隊調崗或者離職時，那些對于平穩運營來說不可或缺的API就會成為“孤兒”。有時，API所有權的轉移非常明確——但更常見的情況是，這個過程會被跳過或通過非正式手續完成。

為每個API分配所有權是清單盤點過程的一部分，它至關重要，因為這樣可以確立問責制，幫助責任人合理地管理和防護他們負責的API。

4. 多個API在執行著類似或重復任務

當多個團隊有相似但不完全相同的需求，通常會發生任務重合的情況，而且有人會說：“我們會通過構建自己的API來滿足我們的需求，這樣，我們就可以掌控自己的命運！”但是，擁有多個類似API會增加不必要的技術債務。因此，衡量有多少應用或服務需要使用API，并將其作為關鍵性能指標 (KPI) 之一非常重要。跟蹤這些指標有助于最大程度地提高每個API的可重用性。整合API的另一種方法是轉換到像是GraphQL一類的更靈活的形式。

5. 文檔滯后超過2個版本

文檔對于經驗傳遞、新員工入職培訓和組織彈性至關重要。可惜的是，編寫和維護文檔通常是工程師最痛恨的事情。過時的API文檔通常表明API正在蔓延——因為這說明團隊創建和更新API的速度太快，所以沒時間更新文檔——或者他們可以看似合理地這么解釋他們不更新文檔的行為。在最壞的情況下，過時的文檔標示著其中提到的API是無人維護的孤兒。

慶幸的是，API往往有清晰定義的結構，使其易于理解。良好的API管理解決方案通常包含一個工具，用于幫助開發人員根據API規范自動生成文檔。最常見的例子之一是??OpenAPI規范??。它使用標準格式來描述API，這樣，人類和計算機就可以在無需訪問源代碼或其他文檔的前提下發現和理解API的功能。

6. 項目由于API安全防護而延誤

有好消息？安全團隊會在發布前檢查所有API。壞消息呢？由于API負責人在開發過程中沒有遵循API安全最佳實踐，或者沒有進行充分的測試，因此未通過檢查，代碼被送回返工。還有更好的消息？制定一套一致的通用規則和最佳實踐來幫助開發人員實現絕大部分的要求，并不是那么難的事情——基本方法包括了實施速率限制、加密外部流量，以及要求對密鑰再生進行重新授權等。大多數企業還可以使用高級Web應用防火墻 (WAF) 或其他工具對API網關實施額外的保護，以抵御??OWASP ??列出的10種最常見API攻擊。

更先進的組織機構擁有成熟的SecDevOps能力，可以為每個API進行威脅建模，而且還可能能夠根據可以訪問的數據或服務類型為不同的API指定不同的安全等級。

結論：避免蔓延是一場永無止境的斗爭 以上六個跡象只是API蔓延現象的一部分預警。我們要明確一點——API蔓延是開發人員自主性和微服務DIY思維的自然產物。借助現代開發工具和像GitHub Copilot這樣的代碼自動化能力，構建新的API正變得越來越輕松可行。

應對API蔓延的工作沒有止境。部署API管理解決方案和API網關可以發揮強大的助推作用——如果開發人員不針對API使用APIM（API Management，即API管理）解決方案，網關可能會關閉他們的API——這一要求很苛刻，但對安全防護來說很必要。

幸運的是，??應對蔓延所采取的措施??大多與常見的API管理方法一致。隨著時間的推移，這些措施可以消除技術債務，并避免在開發過程后期或發布后通過補充的安全措施修復API，最終讓開發速度得到提高。

如果說API是企業的生命線，則API蔓延是對企業健康狀況的最大威脅之一。謹慎且主動的API蔓延控制措施會帶來巨大的回報，并且最終會提高開發人員的滿意程度。