什麼是API 優先？
「API 優先」方法是一種開發模型，其中應用的設計從API 開始，然後再編寫程式碼。API 不是事後的補充，而是必要的、確定的產品。整個開發過程從API 規範開始，應用先被概念化為API。這與傳統的「代碼優先」方法形成了鮮明對比。在傳統的「編碼優先」方法中，單體代碼優先，而API 設計則要晚一些。
API 優先策略特別適合微服務架構，因為它可確保應用生態系統以模組化、可重複使用的系統形式開始建置。及早關注API 能夠引起對API 請求和資料的結構的重視，便於API 提供開發人員最需要的功能，避免將開發人員的時間浪費在後被證實為不必要的功能上。
為何採用API 優先模型？
當一家公司採用API 優先模型（進而成為「API 優先公司」）時，它會優先考慮API（包括內部和外部），並認識到API 生命週期對其業務的影響。對於企業來說，API 優先通常意味著更快的上市速度，因為更容易更新和更改後端服務。
除了提高工作效率之外，採用API 優先方法還有助於開發出更強大的軟體。開發人員可以專注於設計，因為團隊不必從零開始，能夠跨專案重複使用其API 和程式碼。由於在編寫程式碼之前就已經解決了大部分問題，因此減輕了工作，進而節省成本。
API 優先模型也能夠簡化API 治理，為維運團隊提供更高的控制力和可觀測性。對API 具有更高的控制力和視覺性有助於團隊了解API 的當前狀態和未來潛力。
API 優先的安全風險
API 通常是開放的，這賦予了它們強大的功能，但也意味著任何開發人員都能存取API。遺憾的是，並非每個開發人員都心思純正。
在建立成功的API 優先模型時，必須集中定義API 安全防護策略，並將安全防護融入整個API 生命週期中。API 優先模型強調以安全防護為中心的理念，因此比以前以程式碼為中心的模式具有更強大的安全防護邊界。
什麼是API 氾濫？
「API 氾濫（API Sprawl）」描述了隨著企業數位轉型而出現的兩個相互交織的問題：API 數量的激增，以及API 跨多個架構和團隊的散亂分佈。
許多因素會導致API 氾濫。其中一些最常見的因素包括：
• 混合基礎架構－ 當今81% 的企業跨三種或更多架構運營，包括公有雲、本地資料中心和邊緣基礎架構。
• 微服務架構－ 隨著新服務的不斷上線，微服務架構的日益普及導致API 端點激增。
• 持續的軟體部署－ 開發人員可以在短時間內快速開發數十個API 或某個API 的多個版本。
• 被遺棄的API－當開發人員轉而支援和處理其他專案時，他們會停止管理和維護先前建立的API。
為何API 氾濫是個問題？
API 氾濫為企業帶來了巨大的營運和安全防護挑戰。隨著跨多個團隊和環境的API 端點的激增，API 的防護和管理成為一項嚴峻的挑戰。對企業而言，API 氾濫通常會帶來隱性成本，例如降低開發人員的工作效率、增加重工、減慢審查速度，這類成本很難衡量，等察覺時往往為時已晚。
API 氾濫的一些主要挑戰包括：
• 缺乏可視性－ 在混合架構中，很難透過統一視圖查看API 流量和配置。
• 缺乏明確的來源－ 開發人員難以找到API 和最新文件。
• 可靠性下降－ 錯誤配置變得更加普遍，容易造成業務中斷。
• 安全威脅加劇－ 不安全的API 端點很容易成為攻擊目標。
• 如欲進一步了解API 氾濫以及它為何構成重大威脅，請參閱我們的文章《應對API 蔓延的五種方法（以及為何應當關注API 氾濫問題）》。
什麼是API 管理？
「API 管理」是指企業用於監督和發布API 的工具和流程。在某些環境中，API 管理特別指在生產環境中管理API 的控制平面，它可定義策略、推送配置、產生報告和警報，並提供所有API 閘道的可視性。
如今，大多數現代應用都使用API 建構而成。API 是一種軟體接口，支援兩個應用之間相互通信，並允許產品和服務之間以請求（request）和回應（response）的形式進行互動。
API 管理解決方案提供了一些關鍵工具和功能，可簡化開發團隊之間發布和共享API 的流程。以下是有助於實現強大API 管理的元件和用例。
基礎架構
• API 管理器— 管理平面（有時稱為「API 管理器」），提供了單一介面來全面管理API 生命週期，包括發布API、監控API 效能和應用存取控制策略。
• API 開發人員入口網站— 開發人員入口網站是一個線上平台，您可以在此發佈有助於API 消費者快速入門的資源，例如外部API 的目錄、完整的文件及範例程式碼。開發人員入口網站還允許第三方開發人員註冊其應用程式並取得API 和JWT 金鑰。
• API 閘道— 可保護並處理後端和API 消費者之間的流量。API 閘道功能包括驗證API 呼叫，將請求路由到相應的後端，實施速率限制以防止系統過載或緩解DDoS 攻擊，卸載SSL/TLS 流量以提高效能，以及處理錯誤和異常。
使用範例
• API 分析— API 管理解決方案透過儀錶板和報告等視覺化功能提供關鍵洞察。API 分析可以幫助API 擁有者深入了解各個維運方面，例如API 指標、使用情況、流量趨勢，以及哪些開發人員是主要的API 消費者。
• API 安全防護— 安全防護是API 管理的一個重要面向：如果沒有強大的安全防護，任何人都能存取您的API 和數據，並透過呼叫不安全的API 來實施惡意行為。API 安全防護包括身分驗證、授權、基於角色的存取控制(RBAC) 和速率限制。
• API 治理— 指在API 和API 閘道中套用規則和安全防護。實作靈活的API 治理模型有助於平衡全域策略，如日誌記錄、錯誤回應代碼和TLS 配置。
• 定義和發布— API 管理解決方案提供了一個直覺的介面，用於定義有意義的API，包括基本路徑(URL)、資源和端點(endpoint)。
API 管理的主要目標是幫助企業監控API 活動，以便根據目前的開發人員或應用程式要求快速回應任何變更。
在API 管理中，重點是管理單一API 的生命週期（設計、發布、操作、監控和棄用）。
什麼是API 閘道？
API 閘道接受來自客戶端的請求（特別是API 呼叫），並將其路由到對應的微服務。它能夠保護並處理後端服務和API 消費者之間的重要流量，從而降低漏洞、停機和效能低下的風險。
如今，大多數現代應用都使用API 建構而成。API 是一種軟體接口，支援兩個應用之間相互通信，並允許產品和服務之間以請求和回應的形式進行互動。隨著API 變得越來越普遍並分散在微服務架構中，需要額外的基礎架構來確保可擴展性和安全防護。
為何使用API 網關？
使用API 閘道意味著您可以維護單一API 網域（例如api.example.com）。透過API 網關，您能夠為所有用戶端提供一個入口點，以便根據使用者要求將請求路由到不同版本的API。API 閘道支援您透過單一請求呼叫多個微服務並彙總結果，從而提供最佳回應。
API 閘道的基本功能
API 閘道既可用於單體應用，也可用於基於微服務的應用。API 閘道具有以下功能，包括：
• 對進行API 呼叫的請求者進行身份驗證(AuthN)
• 驗證請求者是否有權發出請求(AuthZ)
• 將請求路由到對應的後端
• 實施速率限制以防止系統過載
• 實施速率限制來緩解DDoS 攻擊
• 卸載SSL/TLS 流量以提高效能
• 處理錯誤和異常
API 閘道與API 管理
「API 網關」和「API 管理」有時可以互換使用，但實際上並非同義詞。API 閘道是位於客戶端和API 端點之間的資料平面。它是負責路由、策略和安全的單一代理伺服器。API 管理是指在生產環境中管理API 的控制平面。它可定義策略、推送配置、產生報告和警報，並提供針對所有API 網關的可視性。
理想情況下，API 管理平台獨立於基礎架構，支援您透過最適合用例的方式在各種環境中（例如自有資料中心、雲端平台和邊緣節點）自由部署API 閘道。
將API 閘道用於微服務
在微服務架構中，單一API 可能具有數百個端點，單一應用程式可能包含多個微服務，每個微服務都透過API 連線。由於每個微服務會暴露大量API 端點，因此潛在的攻擊面遠大於單體應用。
將API 網關用於微服務能夠簡化客戶端和API 之間的存取與通信，從而降低風險。但API 網關仍然封裝API，這些API 通常是開放的。API 會暴露連接所需的數據，而且還可能暴露敏感數據。
API 安全性
開放式Web 應用程式安全專案(OWASP) 指出了OWASP 十大API 安全風險專案中最常見的漏洞：
API1.失效的物件級授權
API2.失效的使用者驗證
API3.過度的資料暴露
API4.缺乏資源與速率限制API5
.失效的功能級授權
API6.批量賦值
API7.安全防護配置錯誤
API8.注入
API9.資產管理不當
API10.日誌記錄和監控不足
為了保護API 免受這些肆虐的新攻擊，保護API 網關變得至關重要。如欲進一步了解保護API 閘道的重要性，請參閱我們的文章《使用NGINX App Protect WAF 保護API 閘道》。
API 治理
API 治理是指在API 和API 閘道中套用規則和安全防護。實作靈活的API 治理模型有助於平衡全域策略，如日誌記錄、錯誤回應代碼和TLS 配置。
對於任何實施API 優先策略的組織，特別是採用數千個API 的大型組織，透過API 治理確保一致性可以有效應對潛在的API 蔓延。雖然API 治理曾被認為可能會拖慢開發速度，但當現在需要大規模管理API 時，實施API 治理就很有必要。
API 開發人員體驗是什麼？
API 開發人員體驗是指開發人員在與API 互動時所產生的整體感知和情緒狀態。它涉及基礎架構、工具、流程、支援以及其他接觸點，在將API 整合到應用中時，這些元素共同為開發人員提供一種愉悅、流暢的體驗。
想要在平台上的每個接觸點都為開發人員提供優化後的體驗，「API 開發人員體驗」就是這其中的一個面向。透過減少開發人員之間的摩擦，軟體工程領導者可以提高內部團隊開發人員的工作效率，並促進外部開發人員加速採用其API 和工具。
在設計API 時，需要詢問以下基本問題：
• 功能— API 要做什麼？
• 可用性— API 多麼容易使用？
• 體驗— API 使用體驗如何？
在以開發人員為中心的世界中，必須制定一套涵蓋API 生命週期各個階段的API 策略，並努力創造正面的體驗。在設計API 開發人員體驗時，確定與API 互動的人員、定義API 如何運作、優化其可用性以及增強API 的整體感受都是重要的考慮因素。