什麼是 API 節流？
API 節流是限制使用者在一段時間內可以發出多少次 API 請求的流程，應用程式編程介面 (API) 則是使用者和軟體應用程式之間的通訊閘道。例如，當使用者按一下社交媒體上的發佈按鈕，按下按鈕的動作會觸發 API 呼叫，然後由該 API 與社交媒體應用程式的 Web 伺服器進行互動並執行發佈操作。此處所指的使用者可以是真人或其他軟體應用程式。
各種組織都使用 API 節流來實現多種目標，例如安全性、可擴展性、效能、貨幣化、身份驗證和可用性。
API 節流在業務中的真實範例
假設一個人正在透過 OTA（線上旅行社）網站搜尋航班資訊，OTA 網站會從使用者那裡收集資訊，包括出發地、目的地和旅行日期，然後使用 API 從 GDS（全球經銷系統）（如 Sabre 或 Amadeus）中獲取航班資訊。
為什麼企業需要進行 API 節流？
API 是組織最大的資產之一，API 可以幫助網站或行動應用程式的使用者完成他們的任務。隨著使用者數量增加，網站或行動應用程式會開始出現效能下降的現象。因此，為了提供更好的連線狀態或更快的介面操作給使用者，使他們獲得比其他人更好的體驗，API 節流將是一種優雅的解決方案，可幫助組織確保其 API 的公平使用。
API 節流還有助於抵禦拒絕服務 (DoS) 攻擊，在這種攻擊中，惡意使用者會發送大量請求以試圖讓網站或行動應用程式停擺。隨著線上使用者數量越來越多，企業需要實施 API 節流機制，以確保公平使用、資料安全，同时防止惡意攻擊。
API 節流的工作原理
雖然有多種演算法可以用於 API 節流，但以下是所有 API 節流演算法的基本步驟：
- 用戶端/使用者呼叫與 Web 服務或應用程式連接的 API。
- API 節流邏輯會檢查目前的請求是否已超過允許的 API 呼叫次數。
- 如果請求在限制範圍內，API 將正常執行並完成使用者的請求。
- 如果請求已超出限制範圍，API 便會向使用者傳回錯誤，
- 使用者將不得不等待一段預定的時間，或者付費購買更多的 API 呼叫次數。
主要的 API 節流演算法有哪些？
漏桶 API 節流演算法
此演算法使用先進先出 (FIFO) 佇列來保留傳入請求。佇列有明確長度，當收到新的 API 呼叫/請求時，會將其添加到佇列的末尾。此演算法會定期從佇列前端取出一個請求進行處理，如果新請求到達時佇列已滿，則會捨棄該請求。此演算法與令牌桶 (token bucket) 演算法密切相關。
漏桶演算法的優點
- 易於實施
- 以恆定速率處理請求，因此即使請求量激增，系統也不會超載。在某種程度上，漏桶演算法可以在輸入流不穩定時保持平穩的輸出流。
漏桶演算法的缺點
- 由於漏桶演算法使用 FIFO 佇列，因此有得不到處理（飢餓）的可能性。這意味著當佇列已滿而且需要較長時間來處理請求時，較新的請求可能會被捨棄。這是因為請求全部依照順序處理，所以會出現此類問題。
固定窗口 API 節流演算法
固定窗口允許使用者在一段特定時間內進行 N 次 API 呼叫。例如，固定窗口演算法允許每分鐘兩個請求，則時間範圍會被分成固定時段，每個時段持續一分鐘。在一分鐘開始時，計數器設定為零，每收到一個使用者請求，計數器就增加一。如果計數器在時間窗口結束之前達到上限，便會拒絕新的請求。在每分鐘開始時，計數器都會重設為零。
在固定窗口演算法的典型實踐中，每個使用者都有一個唯一的金鑰，以及一個與該金鑰相關的計數器。在固定時間窗口開始時，計數器都會予以重設。
固定窗口演算法的優點
- 與漏桶演算法不同，固定窗口演算法不會導致新請求得不到處理，因為計數器在每個時間窗口開始時都會重設。
固定窗口演算法的缺點
- 在時間窗口開始時，使用者請求量可能會激增。例如，如果有 1000 個請求/小時的限制，則所有 1000 個請求可能是在此時段的第一分鐘發出，這就可能導致系統不堪重負。
滑動窗口 API 節流演算法
此演算法是在發出請求時才啟動時間窗口，藉此解決固定窗口演算法的請求量激增問題。例如，假設系統每分鐘只允許使用者發出兩個請求，但與固定窗口不同，它的時間窗口是在使用者實際發出第一個請求時才開始起算。第一個請求的時間戳記會與計數器一起儲存，並允許使用者在那一分鐘內再發出一個請求。
滑動窗口演算法的優點
滑動窗口演算法結合了漏桶和固定窗口演算法的優點，並消除這兩種演算法的問題。在滑動窗口中，較新的請求不會像漏桶那樣可能得不到處理，它又與固定窗口不同，請求量激增並不會使系統不堪重負。
API 節流的好處是什麼？
API 節流是所有透過 API 提供服務的組織都需要的必備技術。
效能
API 節流透過限制 API 的過度使用來防止系統效能下降。如果一個應用程式有數百萬個使用者，則一個系統可能每秒會收到大量的 API 請求，若要為所有這些 API 請求提供服務，便會降低系統運行速度並影響其效能表現，此時就可以透過 API 節流來確保每個使用者都能獲得服務級別協議 (SLA) 所要求的效能。
安全性
API 節流系統充當 API 通訊閘道，有助於防止拒絕服務 (DoS) 攻擊。在 DoS 中，攻擊者會發出大量服務請求，使合法使用者無法使用該服務。而透過限制服務請求的總數，API 節流可以有效防止 DoS 攻擊。
減少意外/惡意使用
如果 API 由於技術故障而洩露敏感資訊，則 APO 節流將可限制使用者透過受損的 API 來存取未獲授權的資料。
計量和貨幣化
API 是組織最大的資產之一，因此將 API 貨幣化將能為利潤帶來極大貢獻。API 節流可幫助組織測算其 API 的使用情況。例如，一個 Web 服務可能每小時提供 1000 次免費 API 呼叫，但如果使用者每小時需要更多請求，他們就必須為此付費。
驗證
API 節流不一定只用來限制呼叫次數，根據使用者的存取權限，API 節流邏輯也可以只允許他們存取 API 的選定部分。例如，根據請求者的權限，一些使用者可能只能查看其他使用者，而另一些使用者則可以透過 API 編輯使用者的詳細資訊。
API 節流面臨的挑戰是什麼？
在分散式系統中實施 API 節流是一項具有挑戰性的任務。如果應用程式或服務在全球範圍內有多台伺服器，則應將節流技術應用於分散式系統，使來自同一個使用者的連續請求可以轉發到不同的伺服器。由於每個節點上都存在 API 節流邏輯，因此它們需要彼此即時同步，但這可能會導致不一致和競爭情況。
在下方範例中，使用者已經用完每秒限制的五個請求中的四個請求。假設使用者在同一秒內又發出了兩個請求，它們將被送去兩個不同的伺服器處理。第一個速率限制器會從資料庫中檢索目前的計數器並看到 count=4，所以它接受了呼叫；但與此同時，第二個速率限制器也從資料庫中提取資料，同樣看到count=4，這是因為第二個速率限制器是在第一個速率限制器更新計數之前便從公共資料庫中提取該資料。因此，最終兩個請求都得到了服務，使用者實際上每秒獲得了 6 個請求。
解決方法：API 節流系統採用多種方法來解決不一致和競爭問題。在分散式系統中實施 API 節流的其中一種方法是使用黏性工作階段，在此方法中，某位使用者的所有請求始終都由某個特定伺服器提供服務。但是，這個解決方法並不能很好地平衡負載或容錯。
在分散式系統中進行 API 節流的第二種解決方法是上鎖。在上方例子中，當第一個速率限制器存取資料庫時，它會鎖住計數器，因此在計數器解鎖之前，第二個速率限制器將無法存取計數，必須等到計數器更新為 5 時，第一個速率限制器才會解鎖計數器。另一個較流行的解決方法是放寬速率限制，此解決方法可允許每秒多處理一定百分比的額外請求。