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 ）关注我们，并与我们的编辑和其他读者朋友交流。
评论