Amazon web services API网关最佳实践

我们正在考虑利用aws api网关更好地管理api。然而，在企业层面上，最佳实践是什么？是否有必要为所有应用程序团队使用一个公共API网关（在这种情况下，我们可能需要一个管理员来管理这个公共API网关，这会增加开销），或者每个应用程序团队是否应该构建自己的API网关并管理自己的API调用

---

希望有人能分享他们的经验。

我在不同的web/mobile应用程序项目中使用了AWS API网关。让我试着在这里逐一回答你们的问题

基于限制的设计

API网关有一些限制。您可以根据这些限制找到答案。 例如：“每个API的资源”有一个软限制，设置为300，最多可以增加到500。这意味着将来，如果需要超过500个资源，则需要创建新的API网关

因此，最好在逻辑上隔离API，并根据用途使用不同的API网关

REST API、WebSocket API和WebSocket回调API中每个区域的节流限制（软）限制为每秒10000个请求（RPS），令牌桶算法提供额外的突发容量，最大桶容量为5000个请求

因此需要设计基于流量的API网关

有许多这样的限制

基于功能的设计

API网关使用开放式API标准，方便XML/JSON导入和导出功能。因此，如果一个新的API网关是使用应用程序中的一个swagger文件创建的，那么最好不要将其与其他应用程序混合使用

有许多功能，如1）启用API缓存，2）启用节流，3）Web应用程序防火墙4）客户端证书，这些功能对于企业中的所有API都不是通用的。同样，最好根据需求使用单独的API

AWS API网关设计有不同的日志机制，每个API网关实现都需要定制的方法

SDK的生成对于移动开发来说非常方便，同样，将所有API捆绑到一个SDK中并提供访问是没有用的

---

因此，我的建议是根据特定需求为企业使用多个API网关

我在不同的web/mobile应用程序项目中使用了AWS API网关。让我试着在这里逐一回答你们的问题

基于限制的设计

API网关有一些限制。您可以根据这些限制找到答案。 例如：“每个API的资源”有一个软限制，设置为300，最多可以增加到500。这意味着将来，如果需要超过500个资源，则需要创建新的API网关

因此，最好在逻辑上隔离API，并根据用途使用不同的API网关

REST API、WebSocket API和WebSocket回调API中每个区域的节流限制（软）限制为每秒10000个请求（RPS），令牌桶算法提供额外的突发容量，最大桶容量为5000个请求

因此需要设计基于流量的API网关

有许多这样的限制

基于功能的设计

API网关使用开放式API标准，方便XML/JSON导入和导出功能。因此，如果一个新的API网关是使用应用程序中的一个swagger文件创建的，那么最好不要将其与其他应用程序混合使用

有许多功能，如1）启用API缓存，2）启用节流，3）Web应用程序防火墙4）客户端证书，这些功能对于企业中的所有API都不是通用的。同样，最好根据需求使用单独的API

AWS API网关设计有不同的日志机制，每个API网关实现都需要定制的方法

SDK的生成对于移动开发来说非常方便，同样，将所有API捆绑到一个SDK中并提供访问是没有用的

因此，我的建议是根据特定需求为企业使用多个API网关