写点什么

专访 Uri Sarid: Anypoint for APIs

2014 年 3 月 25 日

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 年 3 月 25 日 23:39976

评论

发布
暂无评论
  • Apigee 技术专家谈 API 发展趋势、产品信息和规范标准

    在圣何塞举行的“I love API”会议后,InfoQ有幸与API管理服务商Apigee公司的Ed Anuff 和 Marsh Gardiner进行了交流,谈话中讲到了他们对于Swagger的新发展的看法,以及在IoT(物联网),医疗服务和电子通信领域中API使用的变化的想法。他们还谈论到类似于Swagger Editor的开源产品,API安全管理问题的潜在变化,以及未能实现的超媒体技术。

  • REST 与旅行商问题的设计

    来自CapGemini的Steve Jones最近对Github上某个Nokia API项目的一段文字进行了一番评论,那段文字表示,为基于REST的服务进行设计及文档化API都不再是必要的,HATEOAS就已经足够了。Steve在之前就提到过,他认为如今的IT界推崇技术而冷落思考,他必需指出这个观点是一种糟糕的实践。

  • 十年前只想混一个 Apache 邮箱装逼,十年后却成了顶级项目创始人

    Kylin意味着我的一切

    2019 年 1 月 11 日

  • MuleSoft 发布新的 Anypoint Platform,用户可操控 API

    Mulesoft发布了新的Anypoint Platform主版本,其亮点在于团队协作功能,支持在平台内对API的创建、保存、发现和重用,以及资产的整合。

  • web-view(六):基于 koa 中间件,实现微信一键登陆的后端接口

    2020 年 7 月 2 日

  • Microsoft Graph 统一微软所有 API 的访问

    在旧金山举行的微软Build大会上,InfoQ有机会采访了Microsoft Graph API的架构师Gareth Jones。Microsoft Graph旨在通过提供统一的API端点简化开发人员的工作。微软的产品广泛应用于世界各地的大多数企业中,看看他们在那种规模下如何解决这个问题会很有意思。

  • Netflix API 网关 Zuul 如何做到每秒处理两百万请求

    演讲嘉宾Susheel Aroskar Netflix Senior Software Engineer内容介绍我们是如何有效的在每秒中向数百个后端服务发送请求的?我们又是如何保护这些后端服务免受持续的DDoS攻击和重试风暴?当AWS服务中断时,我们如何保持Netflix正常运作。Zuul——被称为Netflix应用网络的瑞士军刀,它是Netflix的API网关,负载均衡器,反向代理等等。它掌控着Netflix云的所有API流量,并将这些流量分发到多个后端服务上。必要时,它可以保护这些后端服务免受重试风暴,DDoS攻击以及其他服务中断在AWS区域之间转移流量带来的影响。它可以在数千台计算机上平衡每秒数百万个请求,并在故障实例周围智能的调度资源。不仅在处理在线业务的过程中发挥关键作用,Zuul在开发和测试过程中也非常有价值,可用于调试、测试、加载测试新功能。Zuul支持在运行时动态定义新的分发规则,这些规则可以在无需任何部署或重新启动的情况下即时生效。这种切片,切块和更改部分流量分发的功能可以让Zuul执行各种任务,如为单个客户/设备、黑洞恶意流量做Canary(金丝雀部署)/负载测试,以及外科式流量调试。从本质上讲,Zuul构建于Netty之上,是一个高性能,无阻塞的反向代理和7层负载均衡器。它支持多种协议,包括HTTP 1.0,HTTP 1.1,HTTP / 2,WebSockets和Server Sent Events。还提供灵活可配置的传输层安全性,包括TLS,mTLS和应用层安全性,如Netflix特定的安全协议MSL。内容大纲 Zuul概念 - Zuul适合整体Netflix的架构; Zuul设计 - Zuul架构及其基本组成部分; Zuul运维 - 我们如何运维80多个Zuul集群来代理数百个后端的流量; Zuul未来 - Zuul的下一步打算。

    2019 年 1 月 2 日

  • 智能音箱的战斗:语音助手 Alexa

    Alexa原是Echo音箱的语音助手,在后续发展中独立出来。亚马逊又围绕Alexa平台构建生态圈,从而打开一片新天地。

    2017 年 12 月 13 日

  • APIController:定义 API 的最佳实践

    2020 年 2 月 20 日

  • Elasticsearch 简介及其发展历史

    2019 年 6 月 24 日

  • API 设计中人的因素:专访 Apiary 的 Jakub Nesetril

    API的设计与描述并不仅仅是机器之间的技术接口。Apiary的联合创始人兼CEO Jakub Nesetril指出API描述的真正使用者是开发人员,需要考虑到开发人员的参与、可用性以及交流等方面。最近,就API设计以及API工具和工作流,我们与Apiary进行了交流。

  • 服务网格如何推动云与安生 App 开发的转型

    本文来自RancherLabs微信公众号

  • 采访 Ross Mason:MuleSoft 的新 API 平台

    MuleSoft最近发布了他们的Anypoint平台,该平台支持云和on-premise服务的开发、部署和集成。InfoQ有幸在全球Mule Summit tour期间采访了MuleSoft的CTO,Ross Mason,并和他讨论了这个新平台。Ross曾经创建了开源的Mule项目。

  • Layer 7 调查——超媒体 API 预计会强劲增长

    近日,Layer 7发布了针对API设计和部署的调查结果。调查显示,API设计人员在安全性和可用性哪个应该最先关注方面存在分歧,XML表示和JSON表示占比基本相同,超媒体风格的API预计会强劲增长。总之,调查表明,没有一种放之四海而皆准的API管理方式。

  • APIs.json: 用于发布和发现 API 的工具

    APIs.json是一种API的定义格式,这种格式的文件可以用于向外界传达某个网站所提供的API,并将他们的API开放给搜索引擎,从而可被发现。APIs.json与robots.txt有些类似,robots.txt是一种被搜索引擎用来索引网站内容的文件,而APIs.json则被应用于API的发现和索引。

  • Dion Hinchcliffe 谈 Web API 的过去与未来

    为了了解Dion Hichcliffe对Web API未来发展方向的看法,InfoQ对他进行了采访。根据10多年的深厚经验,Dion阐述了REST及简单设计如何影响了Web API在Web服务上的最终流行的历史。鉴于Web API在企业的应用日益广泛,Dion阐述了API、平台及网络的过去、现在和未来。

  • 【API 进阶之路】帮公司省下 20 万调研费!如何巧用情感分析 API 实现用户偏好调研

    摘要:自从学习API后,仿佛解锁了新技能,可别小看了一个小小的API接口,用好了都是能力无穷。这不,用情感分析API来做用户偏好调研,没想到这么一个小创意给公司省了20万调研费用。

    2020 年 8 月 10 日

  • PayPal 系列教程(二):解密大规模 API 转换

    第二堂课(总共三次)探究了PayPal是如何应用更多的API优先方法来构建平台服务的。在这篇文章中,我们将会深入了解PayPal是如何管理它们的API组合(Portfolio)的。

  • RAML 的强大功能

    RAML的全称是RESTful API建模语言,这是一种基于YAML格式的新规范,因此机器与人类都能够轻易地理解其中的内容。但RAML的目的不仅仅在于创建更易于理解的规范而已。RAML的设计者Uri Sarid希望使用者能够打破固有的思维,在开始编写代码之前以一种全新的方式对API进行建模。

  • 使用 RAML 与 APIkit 以实现 API 需求层次中所定义的目标

    在这篇文章中,Reza Shafii为我们解释了如何通过RAML、API Designer和APIkit等工具,实现由API需求结构中定义的两个最基本的需求,即API设计与实现。

发现更多内容

第五周作业

Jam

第六周作业

Jam

UML 练习

黄立

作业

架构师训练营第一周

子青

第一周学习总结

Geek_ac4080

架构师训练营第 1 期 第一周 学习总结

tangkangkai

极客大学架构师训练营

架构师训练营大作业

吴吴

我们需要软件工艺

Bruce Talk

敏捷 随笔 Agile

食堂就餐卡系统设计

应鹏

极客大学架构师训练营

oeasy 教您玩转 linux 之 010302 火狐浏览器 firefox

o

架构师训练营大作业一同城快递

邵帅

Nacos如何实现服务自动注册

编号94530

spring nacos 源码阅读 spring cloud alibaba

架构方法--课后练习

Nick~毓

go runtime debug 小技巧

新世界杂货铺

golang debug 后端 runtime

网络安全中的机器学习-恶意软件安装

计算机与AI

学习 网络安全

Spring事件执行流程源码分析

编号94530

spring Spring Cloud 源码阅读 事件监听

食堂就餐卡系统设计

……

架构师训练营第1期 第1周 作业1

tangkangkai

极客大学架构师训练营

第三周总结

Jam

只要我跑的够快,内卷它就卷不到我,一名高中生是如何做到在疫情下涨薪70%的?

程序员DMZ

面试 程序人生

极客大学--架构师训练营1期-第一周总结(vaik)

行之

第四周

Jam

第十三周作业

Jam

架构师训练营第一周作业

木头发芽

项目滞后,如何让自己的技术快速成长

郎哲158

个人成长 舒适区 熟练工

架构师训练营:第一周学习总结

xs-geek

第三周作业

Jam

第十二周作业

Jam

采用docker相关测试

菜鸟小sailor 🐕

架构师训练营大作业二

邵帅

电商管理系统之交易子系统设计(一)

长沙造纸农

系统设计 产品经理 系统架构 订单管理 电商平台

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

专访Uri Sarid: Anypoint for APIs-InfoQ