實現API管理系統的幾個重要關鍵詞

管理API的需求源自於Web API開展業務。從2006年開始，而後逐漸成熟，並在2016年以前進入市場。不管是經過代理現有API的管理網關、自己做爲用於部署API自己的網關的一部分，仍是做爲鏈接層在代碼中，API管理就是針對API進行編輯、測試、發佈、身份驗證，計量，分析報告、監控等。在過去十年中，API管理提供商共同定義了一些使用Web API完成業務的經常使用方法。雖然API技術很是技術化，但它依舊與API業務密切有關，而且經過使用Web提供對數據，內容，算法和其餘數字資源的訪問所產生的價值。下面將經過幾個關鍵詞的形式說明API管理的重要性和實現方式。

1.安全性：

API認證

• 若是你常常向合做夥伴提供API訪問權限，那限制API訪問合做夥伴IP地址的防護力（白名單）很是強大。但你仍須要進行身份驗證和速率限制，只要將流量減小到只有已知的合做夥伴，這會消除在對更普遍的互聯網開放的API上看到的大量惡意流量，例如蠻力企圖獲取訪問權限和拒絕服務攻擊。即使使用IP白名單，創建API網關仍然是最佳作法。這有助於身份驗證並確保後端僅接收正確返回的API調用。
• 最多見的是OAuth和OAuth2，用於在API之間進行通訊和保護通訊。即使使用OAuth，其餘人的Token也多是一個問題。如何管理Token的生命週期？Token是否獲得刷新？在一些成功的基礎架構中，使用了一次性Token來嚴格限制正在嘗試的操做類型，它是一種歸結爲安全Token管理和基於證書的身份驗證。
• 在受權以前始終對API進行身份驗證 ，有許多方法能夠進行API身份驗證，但多因素身份驗證是經常使用的方法。對於API，使用外部進程（例如經過OAuth協議）獲取訪問Token是很常見的。身份驗證密鑰最敏感，必須保持安全，建議使用管理存儲來自動執行整個過程。
• 也就是說，僅憑身份驗證不足以授予對API的訪問權限，應該有一個受權步驟來肯定哪些資源能夠訪問API。檢查受權的各類方法包括基於內容的訪問控制（CBAC），基於角色的訪問控制（RBAC）或基於策略的訪問控制（PBAC），這些方法可確保業務數據保持徹底受到保護，以防止未經批准的訪問。

限制訪問API的資源

• 保護API環境涉及每一個API接觸點，對API客戶端（第三方應用程序和開發人員或微服務）進行身份驗證和受權，限速API調用以緩解分佈式拒絕服務（DDoS）攻擊並保護處理後端應用程序API調用。
  用於保護API的一些技術和工具是：
  1）使用JSON Web Token（JWT）來驗證和受權API客戶端，JWT包括有關客戶端的信息，例如管理權限或到期日期。當客戶端向JWT提供其API請求時，API網關會驗證JWT並驗證其中的聲明是否與你爲客戶端請求的資源設置的訪問策略相匹配。
  2）定義和實施訪問控制策略，僅容許某些類型的客戶端執行寫入操做或訪問敏感數據（如訂價）。
  3）定義基於角色的訪問控制，該控制僅容許某些用戶（例如特定組織內的開發人員）發佈敏感信息（如訂價或庫存水平）的API。
  4）經過應用速率限制策略來保護API自己，該策略設置API網關從指定源（例如客戶端IP地址）每秒（或其餘時間段）接受的請求數量的閾值。
  5）使用HTTPS保護後端應用程序 - 應該在API網關和處理API請求的後端系統之間使用HTTPS協議。
• 限制和配額的斷路器，一個好的作法是強制執行每一個應用程序的數據使用配額，以便在DoS，DDoS攻擊或防止未經受權的用戶不正當使用API​​時，後端不會受到影響。每一個資源的節流和配額不只能夠做爲斷路器，還能夠防止系統產生負面影響。具備配額和限制等策略的複雜API管理平臺可提供此功能。

三個關鍵領域

• 咱們的API安全方法的三個關鍵領域：
  1）採用說明性方法。客戶轉向OAuth 2並使用Open ID Connect進行覆蓋，OAuth 2有不少選擇，Open ID雖然限制了選擇但也指導出最佳實踐。
  2）仔細考慮應用程序ID如何與用戶身份相關聯。
  3）從最普遍的意義上考慮API安全性，以減小入侵企圖。能夠採起分發安全實施的方法。默認狀況下，API管理專一於提供API網關，而API網關應該專一於流量的身份驗證和受權。建議採用多層方法，並在Apache Mod Security的單獨層中包含Web應用防火牆。

2.易用性：

部署API有許多重要元素，包括身份驗證，保護/可用性和貨幣化。可是若是不使用API​​，其中許多都可有可無。易於使用和成功完成用例是被使用的關鍵。咱們的集成平臺使API易於使用。
經過咱們的應用程序鏈接器，咱們能夠簡化許多API的使用。

API中的最後一個字母是「界面」，所以明肯定義該界面如何工做是十分重要的。客戶如何使用你的API，以及開發人員如何將這些API推向市場，你須要提早作出一些重要的架構決策。隨着API數量的增加，保持命名和數據格式的一致性變得很重要。當你提供5-10個API時，這並非什麼大問題，可是當數量超過100時，你可能有多我的（或多個團隊）在不一樣的時間段建立它們，做爲不一樣產品的一部分引入等等，讓全部團隊輕鬆瞭解並執行現有規範相當重要。若是這些規範不統一且難以閱讀，那它必定會致使問題。

3.API生命週期管理：

 

具備如下四個主要元素：

• 1.API生命週期管理，提供管理API整個生命週期的能力，從API的設計、開發、發佈和管理（包括維護和版本控制），從而容許公司經過撰寫創新解決方案來加速創新，提升開發效率，促進企業數據的更好安全性，並容許用戶輕鬆發現和使用API。
• 2. API網關，API網關充當一組API的入口點。使用API​​網關的好處是爲每一個客戶端提供最佳API，減小客戶端須要進行的請求數量並實施適當的安全性和控制。
• 3.文件，Developer Portal是提升API採用率和粘性的關鍵。這是開發人員學習和使用API​​的第一點，也是開發人員瞭解身份驗證/受權機制的地方。此外，他們還將瞭解哪些API可供使用，並利用每一個API請求的描述和示例。
• 4. API分析/監控，API分析和監控可幫助瞭解和理解其API的使用狀況，從而提供有關各類API使用的看法。或者，開發者能夠強制執行A​​PI配額，限制和API流量，以阻止/限制與你的業務目標不一致的使用。

在國內的API接口管理工具中，能完整實現API管理全流程而且體驗較好的平臺和工具就是 EOLINKER了，包括接口文檔編輯、API測試、自動化測試和API監控和網關等功能，能體驗到完整的API研發方案。而國外的諸如POSTMAN、Swagger功能也是強大，可是前者注重測試，後者注重接口管理，可能並不全面，並且全英的語言對國人也不是很友好。所以有需求或者感興趣能夠各自了解下EOLINKER、POSTMAN、Swagger。

在選擇API管理解決方案時，最好的建議是始終保持關係簡單，模塊化，強獨立性並與API生命週期中的其餘模塊分離，並保持業務參與度有限，使得能夠在沒有冗長合同的狀況下不斷使用成長。API生命週期中的每一階段都應該反映API的理念，並保持小巧，分離，專一作好該階段目標。

參考資料：

Kin Lane，API Life Cycle Basics: API Management，https://dzone.com/articles/api-life-cycle-basics-api-management

Tom Smith，Keys to API Management，https://dzone.com/articles/keys-to-api-management