转载

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读者交流群 Apigee技术专家谈API发展趋势、产品信息和规范标准（已满），InfoQ读者交流群（#2））。