专访 Uri Sarid: Anypoint for APIs

MuleSoft 近期发布了 Anypoint platform for APIs 的重要更新，对 API 设计、协作及 API 管理特性进行整合。为深入报道，InfoQ 就 Anypoint 平台走访了 MuleSoft 的 CTO——Uri Sarid。

InfoQ**：新版Anypoint platform for APIs含三大组件：API Portal, API Manager和Mule Studio。其中，Mule Studio已经非常出名了，能向我们简单介绍下API Portal和API Manager这两种新组件么？**

US：Anypoint API Portal 被用于和涉众、未来应用开发者共同进行 API 设计，通过 API Console 和 API Notebook 模拟、记录、探察实现前后的 API，使整个开发团队参与其中。Anypoint API Manager 则用于全面控制 API 来访人员、分配访问者的使用权限，以及 API 使用情况的测量分析。

InfoQ：你提出过**"设计先行"方法学： API契约作为主要工件，而具体实现要遵循契约。能谈谈你为API**开发者拟定的工作流类型或生命周期么？

US：与其他产品设计相似，一旦精工细作且用户（这里指开发者）体验尽善尽美的产品推出（此处指 API 发布），就会带来不成比例的高收益。所以要通过 RAML （RESTful API 建模语言）大致勾勒出同时适用于该领域和主要用例的 API，并尽快交给测试用户。即便是在粗略成型的早期，也要有可用的 API 控制台和服务的模拟实现，以便用户体验原型（例如，移动应用原型），还要有可用的“故事板”（scripting notebook），以便他们尽快制定出使用方案并进行成果分享。设计很重要，因为如果 API 设计卓越，围绕其开发出的生态体系会自带动量，从而避免 API（后期）的重大变革。API 的设计要持续迭代到涉众满意后，才着手实现——相信那时，可靠的实现会让开发者们皆大欢喜，并带来理想收益。很多情况下，API 的实现是与大量现存内置系统及云端系统的交互练习；Mule Studio 及其组件 APIkit 能很快将 RAML 规约转换为相应的可扩展、可维护的 Mule 集成流集合。所生成的 Mule 应用能部署在 CloudHub 或内置系统（私有云）上，而对外公开的 API 则自动和 Anypoint API Manager 绑定，以便策略施行；同时，这部分 API 会和 Anypoint API Portal 绑定，以便应用开发人员发现并保存。

InfoQ**： APIKit**** 首次发布时用Swagger作为文档格式。如今转用RAML**。这种转变的动因是什么？有没有API文档方面的教训？

US：简单说来，和 API 领域其他很多人一样，我们认识到：Swagger 和简单格式也许适合作为 API 的“输出”格式，一种在其存在后再表达出来的东西，但不适合 API 设计。不会有开始就动笔写 Swagger 的人；Swagger 是从代码中生成的，也就是说，API 的设计应当源于实现，而 Swagger 有点本末倒置了。此外，Swagger 的描述相当冗长，很容易不得要领：乱花渐欲迷人眼，势必难以构建，而少数整洁的模式显然是能在整个 API 中复用的。用 RAML，是为了让 RESTful API 的设计表达同 REST 本身一样整洁、富于表现且高效。（教训的话，）目前还好。

InfoQ**：Service Registry有变化么 **?

US：Service registry 还是那个存放所有服务注册表的上佳选择，无论是对 REST，还是对 SOAP，甚至对很多像 FTP 位置一样压根不调用 API 的服务。不过我们新添了很多 API 专用特性，比如新策略，和 AnyPoint API Portal 的集成还有更多和现存客户系统的集成。

InfoQ**：有些API不是用Mule实现的，API Manager能管理这部分API么？Mule API和非Mule API在与平台交互时是否存在差异？**

US：Anypoint API Manager 可以通过 API 网关代理控制那些不是用 Mule 实现的 API。从管理甚至端口的角度看，这些 API 要保证所有功能可用，因为如果用 Mule 实现就该是这样。

InfoQ**：在你看来，API剩下的最大的挑战是什么——无论是对提供者还是使用者？**

US：现阶段看，API 正值黄金时代，不过还是有巨大的提升空间：很多企业还没有推出公开 API 倡议。API 设计在不久前还被视作严格规范，最佳实践的数目极少也很少出现；即便是同一组织，API 交互的一致性也很难保证。那些看起来是做了再想该怎么做的 API，使用者宁愿不用——API 是没想好就做的还是用心设计过的，一用便知。

查看英文原文： Anypoint for APIs: An Interview with Uri Sarid

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。