Apigee 技术专家谈 API 发展趋势、产品信息和规范标准

在圣何塞举行的“I love API”会议后，InfoQ 有幸与 API 管理服务商 Apigee 公司的 Ed Anuff 和 Marsh Gardiner 进行了交流。今年四月 Apigee 公司在纳斯达克上市，引起了业内外对于 Apigee 公司和 API 产业的普遍关注，Apigee 公司现在也将研究领域从 API 技术转移到新的版块中，着手于研究应用程序开发和人们对 API 的使用习惯。

InfoQ: Apigee公司在过去的几年内发展迅猛。Apigee对API**** 开发者以及他们的团队提供了哪些技术？

Ed Anuff: Apigee 公司的根本出发点是 API 管理。公司旨在让 API 的开发人员更便捷地在他们单位内外使用 APIs。除此之外还有许多方面，比如说 API 设计这个方面，我们推出了 API Studio 这款产品。我们帮助开发者使用已有的记录系统，然后将其转变成参与系统以支持数字化体验。

Marsh Gardiner: 解决如何将不同类型的数据类型和不同类型的应用程序互相连接是一个很大的问题。我们思考了很多有关于后端系统的问题以及应用程序（比如移动应用程序，IoT 等等）怎么开发的问题。

InfoQ: 在你们的大型企业和SMBs客户中，API的应用和成熟度到什么水平了？

Ed: 现在在 APIs 这个问题上与之前不同的是所有人都在使用 APIs。 我不知道这些使用者是不是充分了解了 APIs，REST 和所有的精妙之处。现在的问题是他们到底运用了多少 APIs。自从我四年前加入公司以来，APIs 的使用呈现了爆炸性的增长。

有许多公司考虑去做 APIs，所以他们就着手开始做了。但是这并不代表他们是这方面的专家。APIs 不像数据库。所以接下来，人们开始注重想要去理解如何设计 APIs，如何管理 APIs 的生命周期。

Marsh: 我们的大客户通常在记录系统 (SoR) 上耗费大量资金，然而他们现在正在尝试着想把记录系统 (SoR) 中的数据转移到应用程序，参与系统中去。大公司通常是尾大难掉，所以让它们换一个角度思考 APIs 对于它们企业的重要性非常困难。

InfoQ:在会议上，Apigee公司强力支持API设计第一的方法。你可以描述一下这代表着什么？现在API**** 设计第一的方法是否有重大的改变？

Marsh:我们公司现如今研发 API 的时候遇到了挑战。如果我们五年前在 Google Doc 撰写了 API 规范说明，然后把它交给开发团队，那现在你就可以获得一些更符合设计文档的资料。

这有几个问题：你不可能在你的设计文档中把所有细节都写得面面俱到，另外在实现过程中的阐述也是被允许的。更重要的是，设计需要发展，因此在你的实现过程中，从哪里起步只是一个很好的设想。

说设计第一其实有一些轻微的误解，因为设计第一意味着设计阶段的结束。这个契约型开发过程的美丽之处在于设计和实现过程可以迭代并行。API 的设计当且仅当你满意的时候才结束，你愿意使用这个版本很长时间，你也愿意邀请别人一起来使用它。

最后一个对于旧方法的挑战是客户在服务发布之前并不能参与构建这些服务，但是如果你拥有一个类似于 Swagger document 的正式规范说明，就可以驱动一个模拟服务使得客户使用和服务端开发同时进行。

InfoQ：你们公司在五月发布了 API Studio的测试版本。你可以描述一下它提供什么服务，以及它与开源软件Swagger Editor之间的区别吗？

Marsh: API Studio 集合了类似于 Swagger Editor 的一系列我们曾经推出过的开源项目的优点，但它加入了一些你使用单一的服务器端组件做不到的内容。因为 Swagger Editor 是基于浏览器的客户端，为了得到适用的模拟服务，你必须有一个合适的服务器端组件。

Ed: Swagger Editor 是一个开源产品，Apigee 是它的主要开发者。它使用了 Node.js 和后台，由于并不是所有人都愿意亲自安装它，所以要做的第一件事是在云端安装托管版本。之后，许多优秀的类似于模拟服务的功能就可以添加进去。

Marsh: 另外一个重要的功能是， API Studio 可以让使用者和他人一起协作处理 API 规范说明。

InfoQ: WADL在Apigee API Console中用于提供API合约，而Swagger是Apigee API Studio的基础。那你们计划如何推动API**** 语言支持的发展呢？

Marsh: Apigee API Consoles 在 Swagger 推出前就已经存在了。在当时 WADL 对它们来说都是很好的格式，但我们最近正在致力于为 Swagger 构造一套标准体系。

Ed:有些人也在做一些比如说 RAML 和 API Blueprint 的好的产品，但是我们想专攻于一个产品并尽可能把它做到最好。与其他格式之间的导入导出并不是一件难事。

InfoQ:Apigee在Swagger的开发过程中已经做了很多，特别是Swagger Editor的开发。那最近Swagger赞助了另外一个API解决方案供应商SmartBear，这会改变你们再这个项目上的付出吗？

Ed: Swagger 开放的基础部分的创造需要大量的工作，我们支持参与了其中的很大部分。这直接影响了最近 Linux Foundation 主持的 Open API Initiative(OAI) 项目的启动。

Marsh: 我们将会持续向社区提供 Swagger 规范标准的开源代码。我们坚定地相信 Swagger 规范标准将成为未来的规范格式。

InfoQ: Ed，你最开始开发了支持 Apache Usergrid的技术。这些年这个项目是如何发展的，它怎么能帮助到API开发者呢？

Ed: Usergrid 是一款后台服务，主要设计使用对象是移动应用开发者，但当然其他平台开发者也可以使用。它提供了可扩展的标识和数据存储还有一些其他的服务，例如推送通知。Apigee 公司将它运用在我们的产品中，但它也是开源的。我们把它带给了 Apache Foundation，现在它已经成长为高水准的项目。

许多的开发者使用它，完善它，所以它发展了很多。它基于 Cassandra 系统，开发团队也相应的为其增加了 Elasticsearch。

当然，它也变得非常可扩展，每秒可以响应超过 10000 次请求，这对于 API 开发者来说是个福音，因为它全部基于 REST APIs。我们对于它的发展非常激动，在会议上我们讨论了许多 Usergrid 会话的内容。

InfoQ: Marsh**，你和Martin Nally在会议上发表了有关于 ** Pragmatic REST的讲话，还谈到了服务导向和数据导向之间主要区别。这与经常使用的REST和纯粹的REST原则有什么区别？

Marsh: 最大的区别是纯粹的 REST 有许多制约因素。我们采用了更实用的方法。比如，我们并不主张超媒体必须成为应用程序状态的引擎。我们没有看到对于 HATEOAS（超媒体即应用状态引擎）现在的需求，但我们确实看到了许多 REST 的好处，包括超媒体的好处。

在这之后，有两个角色模型。服务导向对于开发者来说是自然的方法，他们已经思考过实现这些功能的函数。但是数据导向考虑更多的是数据自身如何展现和数据与实体之间的关系。将这个技术运用到我们产品中的最好实现是在 Usergrid 中。

Ed: 超媒体确实是一个未实现的理想模型，但这也是我们不需要监管就实现 API 的唯一方法。每当你监管的时候，你就必须使用 SOA（面向服务的体系结构）。我能理解为什么人们如此想获得超媒体技术，因为所有你想知道的内容都包含在 API 之中。脱离了超媒体，你想知道的内容就全在文档中（包括安全性、监管等等内容）。这就是为什么人们细化它，但想要完全实现它基本没什么可能性。

Marsh: 在我看来，超媒体驱动 APIs 是一种“适时反应战略协定”。这从根本上和合约驱动有翻天覆地的区别。这不是说哪个好哪个不好的问题，它们可以处理不同的情况。

Ed: Zetta.js 是我们的 IoT API 开源软件，它拥有一个非常强健的超媒体 API 来控制设备。这是一个很好的超媒体可以使一切变得可能的例子。

InfoQ: Pragmatic REST**** 如何处理版本管理问题？

Marsh: 在谈话讲话中，Martin 的观点是最好把版本放在子域中。你也能看到破坏协约但不污染自身路径是基本完成不了的。人们通常把它放在资源中，因为在以后人们想要修改的时候它还仍然留有余地，但如果这就是这么做的最好理由，那我认为这并不值得这么做。

InfoQ: 现在API的开发者大多为了保密性依赖HTTPS，HTTP Basic或是OAuth 2进行验证。你认为 JWT/JWE/JWS, HMAC**** 这些新的安全方案还有数字签名会影响面更大还是仅仅提供专业的解决方案？

Marsh: 我不能把 JWT 当作 OAuth 的替代品，它优化了 OAuth。因为它们支持独立验证还包含了有用的信息，所以它可以更好地处理许可证信息。

Ed: JWT 是扩展性的一个很好的解决方案，所以我们都非常喜欢使用它。我们正在慢慢转向 JWT 许可证。

Marsh: HMAC 签名去年开始使用得更多了，特别是把安全问题看得很重的企业用户。他们希望可以通过加密负载来保证完整性。但这样的做法增加了摩擦，也给应用增加了负担。当然，你可以用 SDKs 来处理其中的一些问题，但你现在就有了 N+1 个问题了，其中 N 是你需要支持维护的语言数量。每次 HMAC 签名出现的时候，我都很努力地想知道为什么它是必须的，它是否值得开发者为它承担额外的负担。

InfoQ: 你们的新产品Apigee Sense在安全方面可以帮助API开发团队一些什么呢？

Ed: 有些人会使用 screen scraper 技术和 bots 木马来盗取你网站的内容或是袭击你的网站。现在这也发生在了 APIs 上，Sense 致力于为 APIs 解决这些问题。它使用了 predictive analytics 这个软件，我们已经投入于此很长一段时间了。我们已经获得了 InsightsOne 这所大数据公司的帮助。这个概念是你可以使用机器学习来判断正在调用 API 的是否是合法用户，即使他们拥有正确的凭据。

Marsh: 有了 Sense 的帮助，我们在某种程度上来说处于网络防火墙的保护下。

InfoQ: 你认为现在API测试的主要目的是什么？ API Health 服务这个新产品能起到什么帮助呢？

Marsh: 我们认为现在任何一个 API 需要监视综合流量和基本流量。所以在会议上我们提到了 API uPinpoint，它可以让客户观察基本流量和点到点的性能。但是综合性测试对于 API 的生命周期也非常重要，它可以告诉你最近建立的候选者是否破坏了协约，也可以用来在已知和固定的时间间隔中验证性能。

InfoQ: 从技术的角度来看，未来的APIs发展前景是怎么样的呢？实时处理技术、webhooks、 lambda表达式和微服务架构会从根本上改变我们未来开发APIs**** 的方式吗？

Ed: 我认为 webhooks 是一个很重要的事物，虽然没有人在 APIs 中讨论它，但它其实是一个非常令人兴奋的事物。你在 GitHub 或是 Slack 或是另外一些地方看 webhooks 的时候会发现，人们目前在用它来处理 SaaS 可扩展性。我认为它比微服务架构占更大比重。

我用“two-way APIs”这个词来描述它。微服务架构属于单向 API。但是如果使用了 webhooks，服务端就可以调用其他应用程序了。许多人因为 Slack 的缘故开始了解并探索 webhooks。

Marsh: webhooks 的一个让我感兴趣的部分是它如何倒置授权服务。传统的 APIs 会把 OAuth 协议作为使用标准，但是如果你使用的是 webhooks，你调用系统，并验证请求的来源是非常常见的，就像 API key 一样是一个公开的秘密。由 webhook 的接收者来决定是否要验证许可证。

Ed:所有人都在讨论微服务架构，但我不知道是不是每个人都认同这个架构，然而所有人都在使用这个术语就像使用 REST 一样。就像我之前曾说过的一样，“如果你喜欢微服务架构，你将会爱上 SOA！”

查看英文原文： Apigee Technologists Explain API Trends, Products, and Standards

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。