发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

专访 Uri Sarid: Anypoint for APIs

  • 2014-03-25
  • 本文字数:1762 字

    阅读完需:约 6 分钟

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

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

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

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

2014-03-25 23:391354

评论

发布
暂无评论
发现更多内容

Linux入门(二) ~ Linux的常用命令

Java 程序员 后端

Linux常用命令(面试题)

Java 程序员 后端

markdown+七牛云,让写文更容易

Java 程序员 后端

MyBatis的Mapper接口以及Example的实例函数及详解

Java 程序员 后端

MyBatis事务管理

Java 程序员 后端

mybatis常用注解(绝对经典)

Java 程序员 后端

Mybatis开发要点-resultType和resultMap的区别?

Java 程序员 后端

MyBatis 框架系列之基础初识

Java 程序员 后端

Memcached缓存

Java 程序员 后端

MongoDB :第六章:Java程序操作MongoDB

Java 程序员 后端

MyBatis 源码分析 - MyBatis入门

Java 程序员 后端

Kubernetes任务调用Job与CronJob及源码分析

Java 程序员 后端

Kurento实战之四:应用开发指南

Java 程序员 后端

Linux系统:第六章:Linux服务

Java 程序员 后端

Linux系统:第四章:Linux文件系统

Java 程序员 后端

Log4j2的Appenders配置详解

Java 程序员 后端

Linux下jdk的安装卸载切换

Java 程序员 后端

MyBatis官方文档-XML 配置

Java 程序员 后端

keepalived实现双机热备(1)

Java 程序员 后端

keepalived实现双机热备

Java 程序员 后端

Layui图片上传组件使用指南

Java 程序员 后端

Mybatis一二级缓存实现原理与使用指南

Java 程序员 后端

MyBatis常用标签和注解(绝对经典)

Java 程序员 后端

K8S环境的Jenkin性能问题处理续篇(任务Pod设置)

Java 程序员 后端

Kubernetes 常用命令大全

Java 程序员 后端

Kurento实战之一:KMS部署和体验

Java 程序员 后端

Linux极速上手,超全面总结

Java 程序员 后端

MyBatis初级实战之二:增删改查

Java 程序员 后端

MyBatis初级实战之二:增删改查(1)

Java 程序员 后端

Mybatis如何执行Select语句,你真的知道吗?

Java 程序员 后端

mybatis映射器组件

Java 程序员 后端

专访Uri Sarid: Anypoint for APIs_语言 & 开发_Saul Caganoff_InfoQ精选文章