Uri Sarid 介绍 RAML 1.0 的发布以及 MuleSoft API 的最新消息

Uri Sarid 是 MuleSoft 的 CTO，在他们于旧金山举办的 CONNECT 2016 年会上，InfoQ 有幸与他进行了交流。Sarid 是 RAML 的创立者，这个项目刚刚发布了人们期待已久的 1.0 GA 版本，因此这是一个很好的机会对去年与他的交流进行随访，并在更宏观的视角上了解MuleSoft 针对API 团队所给出的解决方案以及他对API 的见解。

InfoQ：您在 MuleSoft 担任的角色是什么，API 在你工作中的作用是什么？

Uri Sarid：我的角色是 CTO，这意味着我要负责平台愿景和方向，同时还要负责它的架构。在我们做的所有事情中，API 都是前沿和中心。它是我们工作方式的核心，我们将其称为以 API 为导向的连接，这种方式能够产生一个基于服务的生态系统，我们称之为 API 经济（API economy）。

InfoQ：在 API 方面，MuleSoft 的愿景是什么？它主要来源于集成方面的需求吗？

Sarid ：MuleSoft 的愿景是让我们的客户和整个行业创建应用网络（application network），通过这种方式，连接世界范围内的应用数据和设备。应用网络是由应用程序、数据和设备所组成的网络，它们通过 API 连接起来，实现可插拔（pluggable）的功能并创建可重用的服务。

InfoQ：针对 API 项目，MuleSoft 提供了什么产品来帮助开发人员和架构师吗？

Sarid：我们提供了一个平台而不是一组产品，以便涵盖 API 完整的生命周期。如果你在创建 API 的话，这意味所有的事情会从你想要和尝试创建的内容开始，一直到 API 接口的产品化、功能的实现、部署、运维和管理，再到查看它的运行情况，用户的参与度以及 API 功能的废弃。

InfoQ：在大型的企业和中小型企业（SMB）中，你所看到的 API 采用和成熟情况是怎样的？

Sarid：首先，对于 API 重要性、收益和投资的理解，已经跨越了鸿沟，形成了共识。对我来说，如果具有一定规模的企业不去理解 API，并在核心战略和业务上积极集成 API 的话，这是很难想象的。

值得一提的是，在所需的相关技术以及如何将其做好方面，市场还远远没有成熟。

InfoQ：你认为集成 PaaS（iPaaS）和 API 管理最终是否会合并，还是会基本保持独立？

Sarid：按照我们的观点，它们已经合并了。我们的平台是针对 iPaaS 和 API 管理的综合性解决方案，并且我们看到客户希望有这种类型的完整方案。

客户看到了 API 管理和分布式 ESB 的价值。在有些地方你会需要 iPaaS，客户越来越不再将其视为不同的解决方案。

关于这个问题，有一个很好的样例就是客户希望他们使用 ESB 来创建集成，在此之上能够有管理良好的 API，这样他们就能非常容易地访问所需的数据。

InfoQ：你刚刚宣布了 RAML 1.0 的 GA 版本，这其实经历了很长的成熟期。你能介绍一下它有什么新特性吗，它的交付为何花了这么长的时间？

Sarid：主要的变化在于现在能够以一种格式独立和可重用的方式很容易地为数据建立模型，更容易地重用约定、模式以及自己或别人已开发过的任意内容。

借助 RAML 1.0 ，API 开发人员能够跨网络组件创建和重用设计库，这提升了设计的一致性并且能加速 API 的交付。除此之外，注解提供了强大和可控制的扩展性，而基于 YAML 和可命名的实例增强了人类的可读性，简化了协作以及开发人员的学习过程。

InfoQ：相对它的替代方案和类似产品，RAML 的采用情况如何？

Sarid：目前我们看到的现状，同时也是我们希望的发展方向就是人们意识到 API 作为一种契约的重要性。这种想法会鼓励开发人员选择一种方式来描述这个契约，因为这对他们的组织是有益的。然后他们就会说，这样做的最佳实践是什么。

将 Swagger 和 RAML 进行对比的话，人们会发现 RAML 在 Open API 规范（OAS，也就是原来众所周知的 Swagger 规范）之上添加了很多的东西。它提供了很多用于功能重用的特性。

我们所交流过的 RAML 用户认为，在描述 API 时，RAML 能够作为实现源码的可选方案，他们正在向社区寻求互相交互的工具，这样的话，他们就能充分利用 API 生态系统，在这个过程中，只需规范在各个功能间兼容即可。

InfoQ：你们计划何时发布完全支持 RAML 1.0 的工具呢？

Sarid：我们已经发布了 RAML 1.0 工具的早期可用功能，但是这里还有一些差异。我们发布的所有的解析器已经弥补了这些差异，目前我们正处于最终的阶段，将这些解析器纳入进来并将它们发布到完整功能的平台中。

现在，解析器和 API 工作台都是开源的，这样就允许社区并行地完成对 1.0 版本的支持。

目前，社区项目已经有上百个。它们对 1.0 版本的支持应该在未来的几周或几个月内进行，为了实现这一点，会有很多的文档，甚至还有一个测试兼容性工具箱（Test Compatibility Kit，TCK），从而确保能够实现对规范的完全兼容。

我们正在致力于将 API 工作台模块化为单独的工具，这样它们就能够快速地单独于应用到其他的项目中。

InfoQ：RAML 治理（governance）的演化现状是怎样的？你们有没有计划将其转化为一种标准的形式，就像 Swagger 所创立的 Open API Initiative 那样？

Sarid：目前，治理更多的是社区驱动，并不那么正式。对于采用哪种方式，我们的态度是开放的。在与 Open API Initiative 的协作方面，我们保持了积极的态度，因此在这方面需要进行治理的是同一件事，不过这需要一个持续的对话。

InfoQ：API 的本质是技术化的，但是在软件项目中它的重要性在不断提升，你认为功能人员和技术人员之间的鸿沟该如何进行弥合呢？

Sarid：我认为与其让技术部分更易于访问，还不如让业务人员更易于使用 API 这种方式。假如公司中的某个部门需要数据源中的特定集合，业务人员肯定会问，为什么不构建一个应用网络，让它们都变成可重用的资产呢？你展现给他们的是一个 API，它会驱动对数据的访问。这比只关注 API 控制台的易用性价值更大。

InfoQ：在你的经验中，对于 API 开发人员，从代码驱动到契约驱动的 API 开发流程转换需要多长时间？对于这种更为工业化的阶段，API 工具是否已经准备就绪？

Sarid：尽管很难量化，但是这种运动确实正在发生。我们看到了更多的宣传，但是当我们三年前推出 RAML 的时候，感觉就像是沙漠中孤独的呐喊。随着使用 API 契约的工具逐渐成熟，开发人员看到了不断增长的便利性以及设计优先所带来的时间节省，所以毫无疑问，它不仅仅是一种最佳实践了——它还是一种非常实用的方式。

InfoQ：在 Web 领域，似乎 RPC 有一种持续复苏的态势，比如 Google 的 gRPC。你如何分析这种现象？

Sarid：我认为这是使用 API 时，不断出现的纠结和摇摆，也就是在强类型、规范以及松散类型、缺乏结构之间做出选择。另外还有结构化的 API 语义（CRUD）和非结构化的方式（调用远程系统上的函数），基于文本的方式（JSON、头信息）与基于二进制的方式（gRPC 或 ProtoBuf），我们将会不断看到人们在这些方案之间摇摆。

我认为在 API 生态系统中，我们的角色就是识别在何时应该使用某种方案，而不是其他的方案，并为其提供支持。你需要通盘考虑老系统和新系统，并且在创建新 API 时，指导做出最优的选择。

InfoQ：你认为超媒体 API（hypermedia API）的现状如何？它是常规 API 的替代方案，还是微软的 Graph API 所暗示的那样，是常规 API 的一种补充？

Sarid：我认为它并不是一种替代方案，它更像是一种演化。超媒体是在 API 中嵌入比数据本身更多的内容，控制其他的元数据。

所以，我认为我们依然需要弄清楚如何以及何时才能获得这种方式的最大价值。对此我非常乐观，基于我们已经完成的工作，在明年应该会有结论，我们将会找到这个最有效的点。

InfoQ：在之前的一个访谈中，Daniel Jacobson 质疑了面向临时 API（ephemeral API）的正式 API 描述语言的价值。你同意他的看法吗，你有没有遇到过这样的场景，比如使用 RAML 正式地规范化 API 比较难以令人满意？

Sarid：我们不能说它没有价值。

有很多的 API 每天都会在演化，如客户端应用的 API。如果你采用 CI/CD 的话，可以使用代码生成、自动化测试来查看它的变更是否会破坏发布版本，不需要在 API 的设计上花费时间，只需暴露 API 规范，并持续地对其进行演化，因为它会在“另一个侧面”为 API 增加价值。

另一方面，有时候为了保持快速进展，确实需要并行进行，借助 API 规范，就能实现这种场景。API 的演化可能并不会像 UI 的演化那样迅速，UI 是构建在 API 上的，在这种情况下，让它们并行地演化并且速度稍有不同是非常有益的，这个过程中，API 规范定义了边界并且将不同团队的摩擦达到了最小化。

InfoQ：在 MuleSoft 围绕 API 的问题，你们有什么痛点和最佳实践吗？你们使用了什么特定的工具或工作流程吗？

Sarid：我们使用的是自己的平台。我们遇到的是每个公司都会遇到的典型问题。它其实就是一种所谓的引导问题（bootstrapping problem），我倡导某种理念并为此创建工具，然后利用这些工具来进行构建，但显然它们还在开发的过程之中。这样的话，就找到了一个持续的需求来提升和扩展我们自己的平台，从而服务于我们的需求。基于这些需求，我们来构建自己的平台，让自己和客户从中收益。所以，我认为这是一个很好的问题。

尽管我们已经为服务创建了 API 并采用 API 优先的方式，但是我认为我们还没有完全解决的一个问题就是如何快速地在一个团队内或跨团队进行协作。我们发现自己的 API 基础设施效率不够高，所以在路线图中会对其进行优先处理，这是因为它不仅会帮助到客户，还会提升我们交付产品的能力。

InfoQ：在 CONNECT 2016 上，你与 Netflix 就应用网络和微服务做过一个 演讲。在这个新的趋势下，API 和 DevOps 的角色是什么？

Sarid：我们看到 API 和运维是微服务的两大支柱。在 DevOps 实践的 Ops 这一部分中，面向容器、高度自动化的协作获得了很多的关注，比如使用 Docker 和 Kubernetes，但是市场开始意识到在高效的微服务中，API 扮演了重要的角色，在这个演讲中，这方面也进行了阐述。

API 定义了微服务的边界，就像一个细胞的边界对于它的正常存活至关重要一样，它会调节输入和输出，在微服务存活的生态系统中，API 扮演了类似的角色。

如果你有很强的 API 意识和 Ops 意识的话，你就可以采用我们在 Netflix 所看到的最佳实践，如使用 Chaos Monkey、Hystrix 等等。

InfoQ：围绕着 Java API，最近 Oracle 和 Google 有一个诉讼的判决。你觉得它会如何影响 Web API 项目呢？

Sarid：我们如今生活在一个非常有意思的时代，在美国，API 是可以申请版权的，但是在欧洲还不行。法院裁定 Google 使用 Java API 的方式是“合理使用”，因此不会受到限制也无需对此付费。我们正在思考这对 Web API 意味着什么，它对于我们的经济发展至关重要。

有两个理由能够让我们保持乐观。首先，在陪审团的最新判决中，结论是 Google“合理使用”了 Oracle 的 Java API，他们接受了 Google 的论据，判定为合理使用，因为开发人员熟悉这些 API，而不是因为它鼓励互操作性（interoperability）。在未来的场景中，目的实际上是互操作性，我甚至希望法庭能够接受合理使用的论据，进一步减少版权诉讼的威胁。

第二个理由就是我们回过头来看一下版权真正保护的是什么，它保护的是某个想法原始陈述的描述，而不是想法本身，也不是这个想法的纯实用性描述。例如，如果只有一种方式来表达某件事情的话，那它是没有版权的；如果表述方式完全是实用性的，没有创新性的话，那也不会受到版权的保护。

如今，通过使用通用的词汇和结构，API 经济已经推动 API 更加标准化、更加简单和可预测，API 也变得更加具有实用性和广为人知。随着 API 越来越具有实用性，它的创新性可能就会减少得多，我们希望法院将来会判定这种 API 根本是不受版权保护的。

关于这个重要的诉讼裁决，我们写了一篇详细的博客文章，如果你希望了解更多的信息的话，可以作为参考。

InfoQ：关于 Web API 未来的前景你怎么看？在推动 API 应用于各种规模的企业方面，你认为下一件重大的事情会是什么？

Sarid：API 已经达到了一定的成熟度，未来的前景在于各个组织如何推动它发挥其价值并实现重用。当你使用 Web API 创建应用网络的时候，它的价值就体现出来了。

我们可以使用 API 来创建无缝的应用程序集合，这些应用能够进行组装和重组，这样的话，业务方面可以获得更大的价值。

将 API 纳入业务流程之中将会发挥它们的价值。例如，如果 Web API 暴露关于自身的元数据信息，那么对它们的发现会更加容易，也更加易于将它们集成到业务流程中，这样能够让业务看到 Web 服务的运行状况。

我认为我们需要更加侧重于 API 的发现和使用体验方面。例如，我们已经在 RAML 中使用格式独立的数据类型，所以开发人员不会受到特定格式模式的困扰，如 JSON 模式和 XML 格式（尤其是对于普通的开发人员）。

我们同时还投入时间到 RAML 规范的样例和 API Notebook 上，所以开发人员能够很容易地看到该如何使用这些 API、用例是什么样子的等等。你将会看到我们和其他的参与者如何让 API 的发现和使用变得更加强大和简便，并且还会看到创建 API 的其他可选项。

查看英文原文： Uri Sarid on RAML 1.0 Release and Latest MuleSoft API News