BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

专访Uri Sarid: Anypoint for APIs

| 作者 Saul Caganoff 关注 1 他的粉丝 ,译者 刘君 关注 0 他的粉丝 发布于 2014年3月27日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

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

USAnypoint 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绑定,以便应用开发人员发现并保存。

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

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

InfoQService Registry有变化么?

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

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

USAnypoint 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)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT