整體發(fā)現(xiàn)策略，應對API蔓延
本文探討了API發(fā)現(xiàn)的重要性，強調(diào)了開發(fā)者門戶和服務目錄的雙重需求。門戶服務于API使用者，提供查找和使用API的便捷方式，而服務目錄則為生產(chǎn)者提供API的完整上下文，包括運營數(shù)據(jù)、合規(guī)性狀態(tài)和服務歷史記錄。結合兩者可實現(xiàn)全面的API發(fā)現(xiàn)，提高開發(fā)效率、安全性和治理水平。
譯自：Tackle API Sprawl with a Holistic Discovery Strategy[1]
作者：Saju Pillai
在當今的企業(yè)中，API 無處不在 —— REST、SOAP、GraphQL 以及更多，以驚人的速度遍布各種環(huán)境和平臺。這種爆炸式增長帶來了一個隱藏的成本：API 蔓延。當團隊無法看到哪些 API 存在[2]、它們位于何處或歸誰所有時，開發(fā)速度會減慢，安全風險會成倍增加，工程師會浪費時間構建已經(jīng)存在的東西。
解決方案不是更好的文檔，而是重新思考你的 API 發(fā)現(xiàn)策略以及支持它的工具。
API 發(fā)現(xiàn)中缺失的一半
大多數(shù)組織使用 開發(fā)者門戶[3] 管理 API 發(fā)現(xiàn)[4]，這些門戶只是可搜索的目錄，工程師可以在其中查找、測試和集成可用的 API。這些門戶擅長為 API 使用者提供服務，但它們只講述了一半的故事。
那么，構建和運營這些 API 的團隊呢？當 API 拋出錯誤時，你該聯(lián)系誰？哪個團隊擁有關鍵的支付服務？它是否符合安全標準？上次更新是什么時候？
這就是過時的 API 發(fā)現(xiàn)方法不足的地方。門戶可以告訴你哪些 API 存在，但不能告訴你有效使用它們或正確管理它們所需的完整上下文。有效的 API 發(fā)現(xiàn)必須同時服務于使用者和生產(chǎn)者。
例如，使用者需要：
? 快速、直觀地訪問可用的 API。
? 清晰的文檔和測試功能。
? 自助式入門。
本質上，我們需要為 API 使用者提供他們需要的，以便發(fā)現(xiàn) API 以進行重用和應用程序開發(fā)。
生產(chǎn)者需要：
? 了解誰擁有什么。
? 治理和合規(guī)性跟蹤。
? 運營上下文和依賴關系。
相反，生產(chǎn)者和所有者需要構建安全、可靠和受監(jiān)管的內(nèi)部 API 清單所需的上下文。
這種雙重需求是領先組織采用內(nèi)部開發(fā)者平臺的原因。雖然門戶處理使用者體驗，但服務目錄捕獲生產(chǎn)者端的元數(shù)據(jù)，從而使 API 真正可發(fā)現(xiàn)和可管理。
它在實踐中是如何運作的
假設一個欺詐檢測團隊發(fā)布了一個用于交易評分的內(nèi)部 API。他們在開發(fā)者門戶中記錄了它，其中包含清晰的規(guī)范和示例。幾周后，移動支付團隊開始構建點對點欺詐檢查。
他們沒有從頭開始構建，而是搜索門戶并發(fā)現(xiàn)現(xiàn)有的欺詐 API。他們查看其文檔，測試一些端點，并以完全自助的方式請求訪問。
但在集成之前，他們需要更深入的了解。這個 API 對于支付處理是否足夠可靠？誰維護它？它是否符合合規(guī)性要求？
這就是服務目錄變得不可或缺的地方。它提供了對組織所有關鍵服務的強大、360 度的視圖。例如：
? 實時運營數(shù)據(jù)：來自 Kong[5] 網(wǎng)關的當前錯誤率、來自 PagerDuty[6] 的活動事件以及來自 GitHub[7] 的過期拉取請求。
? 合規(guī)性狀態(tài)：記分卡結果顯示 API 規(guī)范符合 OWASP Top 10 linting 規(guī)則、可接受的 P95 延遲以及啟用了正確的身份驗證插件。
? 完整的服務歷史記錄：跟蹤跨所有集成工具的每一次部署、事件、配置更改和所有權轉移。
? 團隊上下文：不僅包括誰擁有它，還包括他們的 GitHub 存儲庫、Slack[8] 頻道和隨叫隨到輪換。
移動團隊看到欺詐 API 具有低延遲，通過所有安全檢查，并且具有響應迅速的維護人員。他們通過 Slack 直接向團隊發(fā)送消息，并開始充滿信心地進行集成。
原本可能是數(shù)周的冗余開發(fā) —— 或者更糟糕的是，與不可靠的 API 集成 —— 變成了一個由真實數(shù)據(jù)支持的明智決策。
采用整體方法進行 API 發(fā)現(xiàn)的重要性
關鍵是能夠將 API 發(fā)現(xiàn)的兩方面結合在一起，以獲得 API 環(huán)境的整體視圖。
強大的開發(fā)者門戶將通過品牌化、可定制的門戶為 API 使用者提供服務。然后，開發(fā)人員可以瀏覽 API、訪問文檔、直接測試端點和注冊應用程序。它是任何希望使用 API 的人的前門。
現(xiàn)代服務目錄通過捕獲每個 API 和服務的完整上下文來補充這一點。合適的工具將聚合來自你的工具鏈的元數(shù)據(jù)和實時運營數(shù)據(jù)，例如 GitHub 存儲庫、PagerDuty 輪換、Slack 頻道和部署詳細信息，從而創(chuàng)建 API 生態(tài)系統(tǒng)的實時清單。
為了確保質量和合規(guī)性，你需要一個服務目錄，其中包含根據(jù)你的組織標準自動評估服務的記分卡。這使平臺團隊能夠跟蹤其整個 API 組合中的安全合規(guī)性、文檔質量和運營準備情況，從而將治理從手動審計轉變?yōu)槌掷m(xù)監(jiān)控。
它們共同創(chuàng)造了完整的發(fā)現(xiàn)體驗。開發(fā)人員可以更快地查找和使用 API。平臺團隊保持可見性和控制力。安全團隊可以更安心地入睡，因為每個 API 都有記錄。
投資于全面 API 發(fā)現(xiàn)的組織將在未來避免蔓延陷阱，從而釋放其 API 投資的全部價值。
在此處了解有關 Kong 的 API 發(fā)現(xiàn)整體方法的更多信息 這里[9] 并安排 演示[10] 以探索 Kong Konnect 如何幫助你的團隊提高 API 可見性、治理和重用。
引用鏈接
[1] Tackle API Sprawl with a Holistic Discovery Strategy:https://thenewstack.io/tackle-api-sprawl-with-a-holistic-discovery-strategy/
[2]API 存在:https://thenewstack.io/what-devs-must-know-about-apis-before-designing-and-using-them/
[3]開發(fā)者門戶:https://thenewstack.io/api-management/
[4]API 發(fā)現(xiàn):https://thenewstack.io/api-management/
[5]Kong:https://konghq.com/?utm_content=inline+mention
[6]PagerDuty:https://www.pagerduty.com/?utm_content=inline+mention
[7]GitHub:https://github.com/
[8]Slack:https://api.slack.com/?utm_content=inline+mention
[9]這里:https://konghq.com/blog/product-releases/api-discovery
