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

by Jerome Louvel on Aug 03, 2016

摘要：

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