- 身份验证和授权
- 反向代理或网关路由
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消息传递协议。 两种协议都不是特别适合浏览器或防火墙的协议，并且最好在内部使用。
- 日志