深思熟慮的設計還必須考慮到 API 的性能，如果 API 不能響應越來越多的請求，不能滿足不斷變化的業務需求，不能按預期運行，良好的設計就毫無意義。
與任何性能一樣，API 性能在很大程度上取決於 API 如何響應它收到的不同類型的請求。
比如：我們有一個客戶端應用程序，顯示客戶的當前訂單。應用程序從 API 獲取訂單詳細信息。但現在，客戶表示，他們想查看所有訂單。因此，我們構建了一個“我的訂單”頁面，用於顯示客戶的所有訂單。這意味着，我們的 API 將返回比以前更多的數據，比以前承受更大的負載。
如何確保我們的 API 能夠返回所有數據而不會出現延遲、服務器端錯誤和過多請求等問題?這裏有一些性能提升的最佳實踐：
傳輸數據量大的時候，必然會導致 API 性能下降，而最直接的辦法就是降低 API 傳輸的負載(payload)，我們可以使用 GZip 壓縮來縮小有效載荷的大小，可以在 Web API 上使用 Deflate compression。或者，我們可以將 Accept-Encoding 標題更新爲 gzip。
緩存是提高 API 性能的最簡單方法之一。如果我們的請求相同的 API，那麼該響應的緩存版本有助於避免額外的服務調用或數據庫查詢。
在使用緩存時，您需要選擇合適的緩存淘汰算法，在發生新數據更新時，緩存也要及時更新。
即使是設計最強大的 API，緩慢的網絡也會降低性能。不可靠的網絡可能會導致停機，解決這個也相對簡單，多花錢投資於適當的網絡基礎設施，這樣我們才能保持理想的性能水平。
此外，如果您有大量後臺進程，請在單獨的線程上運行這些進程，以避免阻止請求。還可以使用鏡像和 CDN在全球不同地區更快地服務請求。
API 可能會受到 DDoS 攻擊，該攻擊可能是惡意和故意的，也可能是工程師調用API在某些本地應用程序的循環中執行時故意的。可以通過測量交易並監控每個 IP 地址或每個SSO/JWT令牌的每秒調用次數，對惡意請求進行屏蔽來避免這種情況。
這種速率限制方法有助於減少對 API 的過度請求，並主動監控和識別可能的惡意活動。
工程師們普遍認爲，PUT 和 PATCH 操作會產生相同的結果。他們在更新資源方面相似，但他們各自執行更新的方式不同：PUT 操作通過向整個資源發送更新來更新資源。PATCH 操作僅對需要更新的資源應用部分更新。因此 PATCH 調用產生較小的負載，並大規模提高性能。
不過，即使 PATCH 調用可以限制請求大小，也應該注意它不是冪等的。PATCH 可以通過一系列多個調用產生不同的結果。因此，應該仔細和故意地考慮您的應用程序是否使用 PATCH 請求，並確保在需要時它們可以冪等地實現。如果沒有，請使用 PUT 請求。
如果你應該從這篇文章中學到一件事，那就是這個!日誌記錄、監控和警報是 API 最重要的組成部分，沒有之一。
擁有日誌、監控和警報有助於工程師在發生問題之前對其進行診斷和補救。許多API(基於Express/Node、Java、Go)都有預定義的接口來評估以下內容：
/health /metrics
如果沒有啓用日誌記錄，並且存在潛在問題，將無法跟蹤來源，或特定請求中出現問題的地點。如果沒有啓用監控，將無法從分析角度知道一些問題或錯誤的發生頻率。這將不利於做出合理的解決方案。而且，如果沒有啓用警報，將不知道是否有問題，直到客戶(或更糟糕的是客戶)報告它。這就比較嚴重了!
數據量大時，分頁是個很好的策略，不過分頁也不是銀彈，數據量大時依然會非常慢。一個有效的策略是最多顯示前 100 頁，幾乎沒有人會翻到 100 頁之後。
前後端分離已是常態，對於後端開發來說，最重要的就是設計一個強大的 API，針對 APi 的性能進行適當優化和增強，它可以非常強大，爲企業和客戶提供出色的體驗。作爲負責任的工程師，我們有責任決定如何以高性能的方式構建我們的 API，這可以幫助我們實現和超越我們的目標。
本文地址：https://www.linuxprobe.com/improve-api-performance.html