[本文由 paul bruce 撰写。]
好像挤满了 3scale、wso2、axway、intel / mashery、apigee、akana、ca、ibm、oracle、mulesoft 和 hp 的空间还不够有竞争力， 亚马逊 最近决定涉足以下业务： api-in-the-cloud。但是亚马逊为 api paas（ 平台 即服务）带来了其他人在 api 网关解决方案中所没有的东西：一个有凝聚力的 devops 管道。
api 管理与 api 网关
当您对 api 有一个好主意时，就像一个很棒的博客系列一样，您通常需要一种发布、推广和管理它的方法。这是 api 管理背后的基本思想。另一方面，api 网关只是简单地将现有系统置于开放的 api 格式（如 rest 和 json）的前面，可能是授权和身份验证语义，但肯定会使软件更容易构建在现有系统之上。
与简单的网关相比，api 管理门户通常远远超出这些基本领域，包括 api 基础设计功能（如 apiary 的 api-blueprint）、网关/代理选项、货币化和消费者订阅限制。但主要是，它是关于如何扩展、控制和版本化您的 api 的，当您在他们注册并开始向您最珍视和精心制作的 api 发出请求之前不确切知道谁将要访问它时。
3scale 和 mashery 等公司近十年来一直处于领先地位，真正充实了人们对 api 管理解决方案的需求。 一段时间以来 ，gartner 一直在预测 api 管理空间的增长，尽管他们的预测需要时间才能 真正证明是正确的 。一个全新的竞争层最近才在过去几年中以大企业进入 api 管理游戏的形式出现：ibm、hp 和 oracle。许多这些提供者包括基本的 api 网关功能，但将其与 api-as-a-product 生命周期的其他真正重要的方面包装在一起。
为什么亚马逊还没有完全参与 API 管理游戏……
amazon api gateway 提供的正是它所说的：一个网关，一种使用 api 来处理另一种技术的方法。他们面对的是什么技术？在较高的层面上，答案是他们现有的基于云的计算和请求处理功能，如用于指标报告的 lambda、网络和 cloudwatch。但是 api 网关与 api 管理有很大不同。网关只是公开和处理对服务的请求； API 管理提供围绕该核心功能的增值，例如缓存、速率限制、计费、报告、密钥/凭证管理和实时诊断。
“作为一种 PaaS 解决方案，亚马逊 API 网关将给那些只提供基于云的 API 管理产品的公司带来最大的竞争压力”， WSO2 产品管理副总裁 Isabelle Mauny 说。 “相比之下，我们的许多全球企业客户都依赖我们支持云的 wso2 api 管理器软件和云服务来提供在云、服务器和混合环境中部署的灵活性。”
api 管理空间在过去 5 年中呈爆炸式增长，成为添加到公司 api 解决方案组合中的最有利可图和最具战略意义的产品之一。 据估计 ，到 2020 年，该空间将翻两番，达到 6 亿美元以上，但人们必须预料到亚马逊通过这一举措拥有的不仅仅是 api 网关功能。
由于 api 网关与较大的 api 管理产品不同，亚马逊非常接近于为完整的 api 管理竞争者铺平道路。在 aws re:invent 2014 上，亚马逊推出了一系列 devops 工具，即 codecommit、codedeploy 和 codepipeline，让开发人员直接进入 aws，他们的许多运维人员已经在 aws 上进行虚拟化和大容量存储。在越来越多的开发人员构建 API 以拥有一个让他们仅在亚马逊云生态系统中完成任务的解决方案的世界中，这是很自然的。当移动开发人员需要快速获得大量廉价设备时间用于测试或绿地开发目的时，像 aws device farm 这样的额外津贴进一步增加了交易的吸引力。
坦率地说，现在进入 api 管理游戏有点晚了……除非你比市场上任何其他云提供商有十倍的优势，aws 就是这种情况。如果归结为抢夺市场份额，激烈的武装竞争，亚马逊可以迅速赢得大部分api devops市场份额。但是有多少 api 可以在一夜之间构建和编码，需要立即访问亚马逊云？这不是一个惊天动地的数量，而这正是亚马逊尽管尽其所能，但并未对当前 api 管理领域的思想领袖提出如此大挑战的地方。
查希·莱万-莱维
这对 api 格局有何影响？
3scale 的首席执行官、api 管理领域最早的思想领袖之一史蒂夫·威尔莫特 (steve willmott) 阐明了亚马逊的举措：
“亚马逊的声明绝对是该领域的一个重要发展，表明了 API 和 API 管理变得多么重要。亚马逊在公告中的重点是密钥管理和速率限制的典型网关功能，而我们提供了更广泛的解决方案，还解决了围绕 API 的采用和测量的业务工作流程。所以实际上考虑一下 aws，我们的产品将能够与亚马逊的产品很好地连接起来。”
这些想法反映了核心 api 社区的一个重要方面： 友好竞争 。在与其他主要 api 影响者的讨论中，亚马逊 api 网关团队是否与社区中的任何人就构建什么或如何在更大的 api 解决方案生态系统中定位他们的解决方案进行了联系，这是有争议的。虽然 其他影响者对其作为 api 网关的直接价值持怀疑态度 ，因为它已被亚马逊打上烙印，但其批量定价和低进入门槛使其成为非企业消费者的可行竞争者，有点像 api 管理的讨价还价基础。
随着 swagger 和其他服务描述语言的加入 ，整个事情变得更加有趣，因为许多公司已经在他们的 api 上投入了大量资金，以至于他们也在构建描述符可以立即从 amazon api 网关中受益，只要严格的网关就可以了他们正在寻找。虽然已经有许多 api 网关选项，但一个企业集团对 api 网关解决方案的现有投资可能不会对其他集团以临时方式采用 amazon api 网关构成重大障碍。价格和管道点非常引人注目。
在 apidays san francisco，我看到 netflix 的边缘工程副总裁 daniel jacobson 展示了他的团队如何通过一整套自主开发的工具来提供前门 api 功能，其中一个可以满足他们对 zuul 的网关需求。虽然 zuul 和 amazon api 网关不是直接的同类比较，但它们之间最明显的区别是前者作为开源 发布到 github 而后者不是。似乎 netflix 对代码的一般态度是，如果你不知道它是如何工作的，那可能会给你带来麻烦。不知道 amazon api gateway 的工作原理超出文档中的说明也可能代表同样的风险。
我还与 mashery （英特尔）的平台战略总监 rob zazueta 进行了简短的交谈。由于 mashery 专注于提供一个完整的 api 管理平台，而更不用说对严格网关功能的需求，他的感觉是 amazon api gateway 的到来根本不会取代 mashery 的解决方案，而是可能会为 mashery 的消费者补充它们两个都。在 api 领域竞争时，积极的前景和自信的态度通常总是一个好主意。
这对你有什么影响？
它只是意味着您在基本网关功能上有更多选择，特别是如果您在云中有遗留（全机、非组件化）系统，例如 Web 前端和数据库系统，它们只需要通过 API 进行中间层调解。这也意味着您需要比以往任何时候都更好地了解您在 API 空间中的选择，因为致力于一种管道策略可能会对您的交付线产生积极和消极的影响。
为了简化决定是否适合您的 amazon api 网关的过程，这里有一个快速的利弊表：
您的运营或开发团队已经在使用 aws 您有合规性要求，限制您通过 saas/云服务交付数据知道如何在 hal 或 lambday 中编程你已经大摇大摆地定义了你的 api 你现有的 api 缺少描述符并且你无法通过框架自动生成它们你的 api 仅使用云数据存储你需要连接到场外或内部数据
此列表绝不是详尽无遗的，我们鼓励您加入下面的对话，并提出在您的决策过程中考虑或排除 amazon api gateway 的具体原因。
最后，更多的 api 选项对每个人都有好处，尤其是当人们自己研究如何满足他们的实际需求时。根据 api 策略构建您自己的需求列表很重要，但一定要考虑您的软件交付管道、操作可扩展性和停机响应程序以及安全合规性需求如何影响您的决策过程。
请让我们知道您对此事的挑战和想法。交谈永远是朋友。