AWS网关:何时创建另一个API？

Question

这个概念性的问题在我熟悉AWS之后悄悄地出现在我的脑海中。一般来说，我很好奇是否有最佳实践和/或约定，说明API提供者何时应该将端点分组到一个新的单独的API中(而不是将端点合并到现有的API中)。

为了举例说明，假设服务代表Manufacturers创建了数字钱包优惠券，由Consumers在一堆Mom & pop stores上赎回-- Service可能从事的一些活动包括：

• 从Manufacturers接收数据(以建立数字优惠券)
• 为Consumers提供查找和下载优惠券的机制
• 为Mom & pop stores’支付终端验证优惠券提供了一种方法

顺便说一句，服务也可能需要.

• 根据所涉及的技术(例如，带苹果钱包的PassKit)实现各种端点

So?

使用AWS，很容易模块化一个人的后端(例如，为数据库拥有一个RDS实例，运行一些用于微服务的lambda函数等等)。所有的负载平衡。API增加了这一点，因为每个端点都可以指向不同的东西(lambda函数、通过HTTP的EC2实例等等)。

因此，一种方法可能是在AWS中定义 one API，并在其下面包含所有端点：

API: “Master”
  /coupon
    POST = create a new one (for Manufacturers)
    PUT = update an existing one (for Manufacturers)
    GET = retrieve one (for Consumers)

  /coupon/validate
    POST = verify it’s still valid (Mom & Pop store use-case)

  /apple-wallet
     /{version}
         /passes
             ... per documentation
         /devices
             ... per documentation

但是，对于服务来说，去掉/apple-wallet端点并创建一个全新的、独立的API更有意义吗？

或者，如果服务打算发布供公共开发人员使用的文档，那么将Manufacturer-relevant端点完全移动到单独的API中是否有意义？

由于AWS通过API网关将端点分割得如此简单，那么在什么时候应该(或不应该)有任何标准实践吗？

谢谢你的见解/意见！

Answer 1

我的两分钱。为您的API考虑最终用户。对于每个API集，您将有不同的开发人员最终用户。

您理想的情况是让每个开发人员最终用户只看到与他们相关的API，。因此，您应该根据最终用户将APIs划分为不同的网关。

在你所描述的理论情况中：

• 为制造商创建一个API，以便他们可以与您集成来创建优惠券。如果你在内部进行整合，那么公司的销售人员和预售人员就会与制造商沟通。
• 服务和最终用户优惠券的用户可能最终都是为商店和用户创建界面的应用程序开发人员。因此，为他们创建一个优惠券API

将两者分开也会给您带来安全好处，因为您将保护您的制造商API的知识，使其不受试图攻击它的用户的影响。