- 身份驗證和授權
- 反向代理或網關路由
API 網關提供一個反向代理將請求（第 7 層路由，通常是 HTTP 請求）重定向或路由到內部微服務的終結點。 網關為客戶端應用提供單個終結點或 URL，然后將請求映射到一組內部微服務。 此路由功能有助於將客戶端應用從微服務中分離出來；而且在升級整體式 API 服務時，將 API 網關置於整體式 API 服務和客戶端應用之間，操作會變得非常方便，然后可以添加新的 API 作為新的微服務，同時仍然可以使用整體式 API 服務，直到將來它拆分成多個微服務為止。 由於 API 網關，客戶端應用不會注意到所使用的 API 是否已實現為內部微服務或整體式 API，更重要的是，當對整體式 API 進行演進並將其重構為微服務時，得益於 API 網關路由，任何 URI 更改均不會對客戶端應用造成影響。
- 請求聚合
作為網關模式的一部分，可以將多個針對多個內部微服務的客戶端請求（通常是 HTTP 請求）聚合到單個客戶端請求中
- 服務發現集成
API網關需要知道與之通信的每個微服務的位置（IP地址和端口）。
- 重試策略、斷路器，處理部分故障
實現API網關時必須解決的另一個問題是部分失敗的問題。每當一個服務調用另一個響應緩慢或不可用的服務時，在所有分布式系統中都會出現此問題。 API網關絕不應無限期地阻塞等待下游服務。但是，它如何處理故障取決於特定的情況以及哪個服務出現故障。例如，如果推薦服務在產品詳細信息場景中無響應，則API網關應將其余產品詳細信息返回給客戶端，因為它們仍然對用戶有用。這些建議可以是空的，也可以由例如前十名的硬列表取代。但是，如果產品信息服務無響應，則API Gateway應該將錯誤返回給客戶端。
如果可用，API網關也可以返回緩存的數據。例如，由於產品價格很少變化，因此如果定價服務不可用，API網關可以返回緩存的定價數據。數據可以由API網關本身緩存，也可以存儲在外部緩存中，例如Redis或Memcached。通過返回默認數據或緩存的數據，API網關可確保系統故障不會影響用戶體驗。
- IP 允許列表
- 協議轉換
有些服務可能使用不支持Web的協議。 一個服務可能使用Thrift二進制RPC，而另一服務可能使用AMQP消息傳遞協議。 兩種協議都不是特別適合瀏覽器或防火牆的協議，並且最好在內部使用。
- 日志