API Proxy vs API Gateway 您適合的是哪一種！？

最近，常有人在討論 API Proxy 與 API Gateway 哪個比較適用的課題。我們可以先從幾個基本的前提來看：您擁有後端服務，並希望提供給現有客戶或引薦給新客戶使用。連接後端服務的方式會有很多種 -- 網站、行動應用程式、汽車和其他物聯網設備。因此，您提供了一個 API 服務來與所有需求整合，接下來一切就都會順利正常運作了，對嗎？

說真的，這離現實狀況還有不小的差距，人們會擔心安全性、可用性、威脅和監控，也需要確保企業外部發生的事情不會破壞企業內部的系統。為了應對這些課題，你需要準備個代理的角色。它增加了傳輸安全性、進行監控（SLA、效能）、管理配額和對不同的 API 進行存取授權。我們在這裡要做的就是善加利用您現有的 API 服務，並透過 API Proxy 公開出去。

這裡的關鍵字是「現有」， 只有當您已經擁有 API 時，API Proxy 才能發揮它的功效。當您將組織內部的 API 服務暴露給代理程式時，它不會添加任何新內容，就直接公開出去。然而，對大多數企業來說，這與目前的業務場景頗有出入。

大多數企業都透過由一個或多個應用程式公開現有服務，在企業內部有各種使用這些服務的應用程式，這些應用程式可能會分佈在多個不同的地區。這些都是企業內部已經存在的服務互相串接，而不是以 API 串接的方式進行。

應用服務串接

API 代理集中露出服務

轉化為 API，這就是 API Gateway 的用武之地。API Gateway 可協助您組裝應用服務，將它們拼接在一起以建立 API 服務。接下來，Mediation 怎麼做就是下一個要角了。什麼是 Mediation ？它是從各種後端來源（例如 : SOAP、JMS、POX（甚至現代 API））獲取現有服務，並將資料轉換為供各種使用者使用 API 的方法。我們可以取得這些 SOAP / XML 服務並轉換為 REST / JSON API，或取得 REST / JSON API 並轉換為 SOAP / XML 服務。您的後端是什麼格式以及您希望 API 採用什麼格式，相形之下就顯得不是那麼重要了。

從一種格式轉換為另一種格式，您不需要做的是編寫程式碼（特別是編寫大量程式碼）來執行此類中介，您需要的僅僅是一個能夠無縫執行此操作的 API Gateway。API Gateway 對於安全性的課題，主要在確保負載的端點對端點間具有足夠的安全水準。它不只是處理身份驗證、授權，亦可進行阻斷服務攻擊 ( DoS )、SQL 注入檢查等複雜的交易防護。

另一個問題出現了，API Gateway 可以提供這麼多功能，那我們還需要 API Proxy 嗎？嗯，大多數情況下不是。有些人可能會認為 API Proxy 可能更輕量，當您只需要代理的功能時，為什麼要做這些重量級的事情呢？也有人說，API Gateway 功能龐大，增加了重量，可能會減慢速度。但事實並非如此。

設計良好的 API Gateway 可以充當 API Proxy，基於需求驅動對應的配置，僅在需要時添加額外的功能。那麼回到使用API Proxy 與 API Gateway 的問題，您需要的是在同一個產品中同時使用這兩者！這就是為什麼最好的方法是透過使用 API 管理工具。Axway API Management 就是這麼一套使用輕量級架構的管理工具，透過單一控制點降低風險，而不影響現有的開發中心，集中對 API 進行管理、監控和治理，以建構良好的 API 服務架構。

API Gateway 強化管理