API網(wǎng)關如何發(fā)展：更輕、更智能、云原生
你可能也喜歡這些API文章!
在 REST API 和 Web 服務領域，我們立即面臨著重要的安全任務。網(wǎng)絡威脅無處不在，因此 REST API 的安全至關重要。目標是通過采用強大的身份驗證和授權程序，僅授權用戶執(zhí)行操作。
SSL/TLS 協(xié)議的實施為我們的 (API) 通信提供了安全的通道。此外，監(jiān)控和記錄 API 活動可充當警衛(wèi)，識別和預防潛在威脅。
問題出現(xiàn)了——我們?nèi)绾尾拍苤幌蚝戏ㄓ脩羰谟璞驹L問權限？基于令牌的身份驗證協(xié)議提供了解決方案。這些協(xié)議就像只有授權用戶才知道的秘密握手。其中，JSON Web 令牌 (JWT) 脫穎而出，成為一種流行的選擇，它充當驗證用戶身份和保護堡壘（API 端點）訪問的護照。
然而，這些護照的有效期很短，減少了未經(jīng)授權訪問的風險窗口。因此，JWT 和其短暫性相結合，形成了對入侵力量的強大防御。
然后，我們探討加密，這是我們安全工具包中的一個關鍵策略。傳輸層安全性 (TLS) 加密客戶端和服務器之間的數(shù)據(jù)傳輸，從而保護 API 通信。
API 網(wǎng)關充當保護盾，提供 TLS 或相互 TLS (mTLS) 等功能，這對于實現(xiàn)加密至關重要。這些加密標準類似于只有用戶才能理解的神秘語言，可確保信息的安全交換并阻止任何攔截其通信的企圖。
為保證敏感信息的安全傳輸，應采取以下措施：
通過實施這些措施，您可以有效地保護敏感數(shù)據(jù)并確保 API 中的安全訪問數(shù)據(jù)。
堡壘的網(wǎng)關充當著強大的保護層，在可疑請求到達 API 之前將其過濾掉。同時，Web 應用程序防火墻 (WAF) 可防范 DDoS 攻擊和其他惡意流量。通過實施這些措施，我們確保我們的珍寶——敏感數(shù)據(jù)——得到妥善保護。
結構良好的 API 架構注重設計的技術方面，從而打造高效、安全且用戶友好的環(huán)境。這包括清晰的標識（資源命名）、簡單的路由（HTTP 方法）和結構良好的層次結構（嵌套資源）。
為了提供用戶友好的 API，請對資源集合使用復數(shù)形式（例如 /users），對單個資源使用單數(shù)名詞（例如 /users/123）。這可使 API 直觀且更易于理解。
這可確保您的 API 具有清晰的“標志”，從而方便用戶使用。
標準 HTTP 方法對于在 RESTful API 中執(zhí)行 CRUD 操作至關重要，類似于明確定義的程序指導操作的方式。這些方法是：
在設計端點 URI 時，應使用反映實體的清晰的名詞路徑，并且 HTTP 方法（而不是 URI）定義對資源的操作。將 HTTP 方法與其預期的 CRUD 操作對齊有助于為消費者提供直觀且可預測的 API 交互。
在我們的應用程序中，有許多部分，每個部分都有不同的角色。同樣，在 API 設計中，嵌套或相關資源必須具有結構化的層次結構，以促進協(xié)作并最大限度地減少深度級別。嵌套資源應使用分層 URI 來處理，以反映它們與單獨資源的關系，從而實現(xiàn)直觀的數(shù)據(jù)訪問和操作。
然而，在設計嵌套資源時，必須避免 URL 過長、冗余端點和不必要的數(shù)據(jù)庫查詢，因為這些會使 API 復雜化并降低效率。應謹慎使用嵌套資源，以保持高效、可擴展且易于使用的 API。因此，結構良好的堡壘可讓用戶高效移動和協(xié)作。
有效的響應管理包括使用標準 HTTP 狀態(tài)代碼、制作信息響應主體以及實施速率限制以確保適當?shù)?API 通信。
此請求的結果可以通過一個簡單的標志系統(tǒng)來傳達。同樣，HTTP 狀態(tài)代碼充當這些標志，在服務器和客戶端之間傳達 HTTP 請求（例如 API 請求）的結果。
不同的代碼表示不同的狀態(tài) – 操作成功、錯誤或需要采取其他措施。遵守標準 HTTP 狀態(tài)代碼并避免使用自定義代碼是一種最佳實踐，類似于遵循通用標志代碼，可防止溝通錯誤。
HTTP 狀態(tài)代碼使客戶端無需檢查響應主體即可了解其請求的結果，從而立即清楚了解狀態(tài)代碼和請求的結果。
在 API 世界中，響應主體就像是一份附有標志的詳細報告。在 API 響應的請求主體中同時包含請求的數(shù)據(jù)和相關元數(shù)據(jù)可以提高清晰度并提供關鍵上下文或附加信息。這就像用戶不僅知道他的請求被拒絕，還知道為什么被拒絕。
“X-Request-Id”響應標頭通過跟蹤服務器上的整個請求生命周期來幫助調試特定請求。用戶可以全面了解自己的請求，從發(fā)出請求到做出決定，這有助于理解和改進未來的請求。
為了防止濫用和維持秩序，任何城堡都會限制請求或授予的觀眾數(shù)量。同樣，在 API 設計中，速率限制對于防止系統(tǒng)濫用和保持服務器性能至關重要。
實現(xiàn)速率限制的各種技術包括節(jié)流、請求隊列和基于算法的方法，如固定窗口、漏桶、滑動日志和滑動窗口。另一種策略是負載削減，即在系統(tǒng)接近過載時拒絕 API 請求以確保穩(wěn)定性。
API 通過響應標頭將速率限制和服務器狀態(tài)傳達給客戶端，指導用戶相應地調整其請求模式。因此，速率限制就像守門人一樣，確保堡壘的平穩(wěn)運行。
我們現(xiàn)在專注于應用程序內(nèi)的信息交換。客戶端請求或用戶與服務器之間的高效數(shù)據(jù)交換對于優(yōu)化 REST API 中的客戶端-服務器數(shù)據(jù)交換至關重要。這涉及使用高效的數(shù)據(jù)序列化格式、內(nèi)容協(xié)商和壓縮技術。
在任何對話中，使用的語言都是至關重要的。在 API 設計中，選擇合適的數(shù)據(jù)格式（如 JSON）以實現(xiàn)兼容性和性能，就如同使用一種通用、高效的語言。JSON 數(shù)據(jù)采用鍵值對結構，而 XML 數(shù)據(jù)采用分層樹模式表示，JSON 的簡單性使其更適合 API。了解 API 設計中使用的正確數(shù)據(jù)結構對于有效溝通至關重要。
JSON 文件通常文件大小較小且更易于解析，從而加快數(shù)據(jù)傳輸速度并提高 API 性能。另一方面，XML 支持更多樣化的數(shù)據(jù)類型，在數(shù)據(jù)表示方面提供更大的靈活性。因此，選擇正確的數(shù)據(jù)格式就像選擇應用程序內(nèi)最有效的通信語言一樣。
客戶端和服務器可能需要以各種格式交換數(shù)據(jù)。這時內(nèi)容協(xié)商就派上用場了，讓它們能夠就傳輸數(shù)據(jù)和要共享的文檔格式進行溝通。
客戶端使用“Accept”標頭來指定它們理解的媒體類型格式，而“Content-Type”標頭則指示發(fā)送回客戶端的數(shù)據(jù)的媒體類型。在請求期間，客戶端可以向服務器端發(fā)送一個“Accept”標頭，其中包含“application/json”或“application/xml”等值，以指示其偏好，而服務器則使用“Content-Type”標頭進行響應，以指定發(fā)送的數(shù)據(jù)的格式。這類似于用戶和服務器就對話的通用語言達成一致。
gzip 和 brotli 等壓縮技術可以傳遞簡潔的信息，節(jié)省帶寬并提高網(wǎng)絡傳輸速度。
客戶端可以使用 HTTP 標頭（例如“Accept-Encoding”）來指定它們支持的壓縮方法，服務器可以使用“Content-Encoding”來指示所提供內(nèi)容的壓縮方法。實施這些技術可以通過加速數(shù)據(jù)傳輸和減少延遲來顯著提高 API 性能。
配備高級功能的工具包始終具有優(yōu)勢。在 API 領域，高級查詢功能如下：
通過監(jiān)控和優(yōu)化 API 行為來增強 API 功能。
假設一名抄寫員根據(jù)特定標準對卷軸進行排序。API 世界中的過濾和排序工作方式類似。高效的做法會限制返回的無效數(shù)據(jù)量，從而優(yōu)化性能并節(jié)省服務器資源，尤其是在處理大型數(shù)據(jù)集時。
限制/偏移分頁使用“限制”參數(shù)來定義要返回的項目數(shù)，并使用“偏移”參數(shù)來指定起點，使其在 API 中易于實現(xiàn)。高級過濾機制利用帶有鍵值對的 URL 參數(shù)和運算符（例如“gte”和“l(fā)te”）來表示范圍過濾器。
就像高級搜索選項可以簡化用戶查找所需信息的流程一樣，API 也受益于強大的搜索功能。這些功能允許過濾和選擇特定的數(shù)據(jù)字段，從而高效地檢索所需的內(nèi)容。API 可以通過支持復雜查詢來增強其搜索功能，從而啟用范圍搜索、術語匹配和模糊匹配等操作來優(yōu)化搜索結果。
為了擴展搜索功能，API 可以利用 Lucene 或 ElasticSearch 等高級搜索技術啟發(fā)的語法，在搜索參數(shù)中實現(xiàn)過濾器和范圍。這就像騎士使用高級搜索技術來找到他需要的準確卷軸一樣。
API 也會隨著時間的推移而發(fā)展。版本控制是 REST API 設計軟件開發(fā)不可或缺的一部分，可確保支持舊 API，同時系統(tǒng)地發(fā)布更新和新功能。它能夠以受控的方式引入新功能、糾正錯誤并棄用過時的功能。
選擇合適的版本控制方法類似于規(guī)劃城堡的擴建。URI 版本控制涉及將版本號直接包含在端點 URL 中，這使得實現(xiàn)變得簡單，但會導致 URL 更長。查詢字符串參數(shù)版本控制將版本號放在 URL 的查詢參數(shù)中，從而產(chǎn)生更清晰的 URL。
標頭版本控制將版本信息引入 HTTP 標頭，從而保持干凈的 URL 并節(jié)省 URI 空間，但可能會增加客戶端請求的復雜性。媒體類型版本控制將版本數(shù)據(jù)嵌入 HTTP 標頭中的媒體類型聲明中，從而實現(xiàn)對版本的精細控制。選擇正確的版本控制方法就像為應用程序的擴展選擇最有效的設計一樣。
在 API 設計中，棄用涉及逐步淘汰 API 功能，向 API 消費者傳達這些即將發(fā)生的變化非常重要。
提前宣布變更并提供明確的時間表可確保用戶充分了解新功能和棄用的功能。將用戶過渡到新版本需要提供清晰的文檔和支持以促進更新過程。因此，良好的溝通時間表可確保堡壘的居民能夠順利適應變化。
全面的 API 設計文檔與產(chǎn)品構建和維護藍圖一樣重要。文檔充當 API 的藍圖，為有效的 API 使用和采用提供基本信息。
API 契約類似于服務器和 API 之間的協(xié)議，明確雙方的期望。編寫良好的 API 契約的特點是簡單、一致，并且有詳盡的文檔，涵蓋輸入、輸出、錯誤代碼和用例示例。
開放 API 規(guī)范等開發(fā)工具可以幫助確保傳入的數(shù)據(jù)符合預期的數(shù)據(jù)類型和屬性，在符合 API 契約的輸入驗證中發(fā)揮關鍵作用。通過遵循 API 設計原則，將 API 契約測試自動化作為持續(xù)集成過程的一部分，可以保持對定義的契約行為的遵守。
因此，清晰的 API 合同可確保每個人都知道自己的角色和職責。
繪制 API 藍圖需要一套適當?shù)墓ぞ?。?API 設計領域，Swagger 和 Postman 等工具對于編寫詳盡的文檔和測試 API 至關重要。
Swagger 和 Postman 直接連接到文檔，大大提高了 API 使用者的可發(fā)現(xiàn)性。這就像擁有不僅有助于繪制藍圖而且使堡壘所有居民都可以輕松訪問的工具。
API 的變更都有記錄，就像城堡翻新的更新一樣。使用發(fā)行說明和變更日志來傳達 API 變更可確保用戶充分了解新功能和棄用的功能。
維護變更日志對于通知用戶更新（尤其是重大變更）以及確保其實現(xiàn)的持續(xù)功能至關重要。這就像在堡壘中記錄所有變更，幫助堡壘中的居民適應這些變更。
文章來源：Mastering Good API Design Principles: The What, Why, and How
