【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

从两个风格迥异的 API 平台说开去

  • 2016-11-21
  • 本文字数:3850 字

    阅读完需:约 13 分钟

了解 API

有人的地方就有江湖。有江湖的地方就有纷争。有纷争的地方就有是非。有是非的地方就有无奈。自然,有 API 的地方就有 App。API 已成为 App 的标准之一,被硅谷风投 Fred Wilson 视为成功 App 的关键因素之一。

API,即 Application Programming Interfaces(应用程序编程接口)。简单地说,就是一套套的要求,用来管理应用程序之间的沟通。API 并不是什么新事物,在你使用计算机时,正是 API 让数据在程序之间传输。在互联网中,API 让其它应用可以使用一些大的服务,如 Google Maps 和 Facebook。例如 Yelp,它可以在 Google Map 上显示附近的餐馆;还有一些游戏可让用户通过 Facebook 与其它玩家聊天、分享得分等。

API 是通过把程序内部的一些功能有限地向外开放来做到的,这使得应用之间可基于各自的利益分享数据,同时不需要开发者公布所有的软件代码。对开源项目来说也是如此。你可以把它看成是一扇门、窗或杠杆,不管用什么比喻,一个程序和外面的软件世界的沟通就是由 API 定义的。

API 的魅力在哪里呢?与编程范式比起来,API 在不断酝酿新的商业模式。API 不仅会把所有东西进行技术整合,还会把相应的商业利益或多或少的联系到一起。当开发者开始调用公司 API 的时候,他们就会成为公司的一个合作伙伴,而用户有可能会发展成为他们的潜在顾客。

随着 API 的蓬勃发展,如何维持高质量的 API 也逐渐成为众多公司所关注的问题。如何保证 API 的质量呢?最好就是要确保 API 提供了卓越的用户体验,并与合作伙伴达成合作协议,进而完成业务目标。

为了确保 IT 生态系统的健康和繁荣,开发一个 API 需要一个郑重的承诺,因为它需要长期的维护管理,维持高质量。

如果一家 IT 公司还在为产品的战略和商业模式而感到彷徨无助,那么,等待一个高度可访问的外部 API 是值得的。最好要先了解一下你要去的那家公司,这样就可以利用公司庞大的合作伙伴网络,优势互补协作创新,使你的产品加速发展。如果你的公司正在考虑提供公共 API,这篇文章就是为您撰写的。让我们看一看 Twitter 和 Slack 分别是如何管理各自的 API 的。

Twitter API 和生态系统错位

在 Twitter 的 API 所有变更中,饱受争议的是 Twitter 限制第三方客户端 App 所能拥有用户的数目,以确保这些客户端 App(大部分复制了 Twitter 的核心体验)不能变得足够大,从而失去竞争力。在此之前,Twitter 的 API 提供了大部分不受限制的访问,但没有应用策略。早期 Twitter 极端繁忙,仅仅是为了保持服务正常运行——还记得那头失败的鲸鱼吗?(InfoQ 注:Twitter 宕机的页面是一头失败的鲸鱼图像。)当 API 发布时,唯一的第一方 Twitter 客户端是网站。这个 API,令人难以置信地充斥了当时的主流移动平台(iOS、Android、Blackberry)上的第三方客户端。

在初期时,涌现了许多第三方富有特色的 App,如 Tweetbot、Twittelator、Twitterific、UberTwitter、Seesmic、Brizzly、Falcon 等等,那个时候多么迷人啊。

目前,这个 API 已经有 600,000 个开发人员注册了 900,000 个应用程序,每天疯狂地处理 130 亿个请求。“Twitterverse”是大规模的。在最近的记忆里,这无疑是最让人激动的 API 之一。

然而,Twitter 越来越多深刻地意识到,他们最具 扩充性的商业模式是广告,Twitter 与用户之间的 UI 变得至关重要,这一点,在 Twitter 购买 Tweetie(iOS 客户端)时显得特别明显,此刻,这个新的第一方 App 突然变得与服务本身无法区分。

此外,对于每个大客户端而言,有许多不良的用户体验。这将会给第一次尝试 Twitter 的用户很差的体验,从而流失客户,于是 Twitter 被迫进一步提供第一方移动 App。

但最重要的是,在这个时候,在 Twitter 的生态系统中爆发了一件事。Bill Gross 的 UberMedia 公司开始收购几个第三方 Twitter 客户端:Echofon、UberTwitter、Twidroyd,并寻求收购 Tweetdeck。如果 UberMedia 成功收购了 Tweetdeck,他们将控制一大批客户端:决定多少用户能够创建并使用 Tweets。Twitter 敏锐地认识到,这是一个威胁——如果 UberMedia 创建一个影子网络,从 Twitter 完全引走用户,这将是灾难性的事件。

从某种意义上说,这意味着所有面向消费者的第三方客户和聚合应用突如其来的竞争,导致了扭曲性激励机制,及严重的政策收紧。下面是声名狼藉的“API 象限”。

这很大程度上是因为 Twitter 的 API“黄金时代”结束了。API 是与外部开发者签订的合同,一旦它释放,就如泼水难收。有没有其他方式可以管理 v1.1 的转换,就像没有用户限制的继续不受约束的访问,但针对第三方客户端的广告联合发布模式?是的,绝对有。即使只有一小部分开发人员实质上受到 v1.1 变更的影响(记住,生态系统是巨大的,有许多不同类型的 App),v1.1 的影响通过开发者社区引起了轩然大波,并导致人心涣散,对一个蓬勃发展的平台而言不啻一个打击 。

Slack 的 API 和结盟激励

通过考察 Slack 管理他们的 API 生态系统的方式来对比 Twitter。Slack 有意使激励与他们的生态系统相符,侧重将他们的服务融入到免费 App 中。例如,Slack 的 API 上的一些顶级 App 涵盖了项目管理、日历控制、费用会计等功能。这些使用范围和权限子集(通过 OAuth)的 Slack 应用程序在进行审核后显示在应用目录中。这个目录有助于提高发现和分布,对于消除摩擦和为应用程序提供他们需要的用户流动性不可或缺。

这些第三方App 以互补的形式,丰富了Slack 核心体验。这对所有的参与者都有好处:用户获得更好的体验,开发者获得更多的用户,Slack 比闭门造车得到更多的功能,激励与动机相一致。Slack 采取积极的方法来指导和管理它的生态系统。尽管发布一个必然改变的路线图有风险,Slack 还是这样做了。此外,他们提供了一个“ Ideaboard ”来传递他们从客户那里得到的市场反馈 ; 让开发人员了解客户需要解决的问题。

也许最令人印象深刻的是,Slack 组建了一个 8000 万美元的基金,直接投资第三方 App。这就是 Slack 的口号,为开发者社区提供资金,并允许他们在建立业务时维持运营。Slack 已经为 14 个 App 投入了近 2 万美元,特别侧重于 bot 风格的 App。这是一个了不起的方法,确保最好的 App 得到奖励,鼓励保持高品质的体验。

管理生态系统

所以我们回到许多公司面临的一个常见问题:他们是否应该开放 API 来成为一个数据服务或平台?开放 API 是一个巨大的承诺,很容易低估随健康的生态系统而来的工作量。为了完全公平应用 Twitter,API 在初期令人难以置信的启动了,在商业模式设想出来之前,很显然存在由局外人引发客户端合并的威胁。

这使得该公司很难继续开发一个开放的 API,并同时促进健康的广告业务。记住,一家公司在其高速发展阶段有巨大的期望,特别是当公司要赚很多钱时。这里也很重要的一点是,在早期建立客户端的第三方开发人员受益匪浅:他们拥有自己的用户(Twitter 用户的一个子集),开发者社区积极的社会关注,他们中的许多人赚了数量不等的钱(有些人赚了非常多的钱)。

健康的 API 应该为提供商带来双赢:第三方 App 开发者和用户。如果你的公司计划提供一个 API,并且你想促进一个强大的生态系统,你必须大量投资。你必须不断努力,让开发者社区获得成功。仅仅发布 API,并希望事情顺利发展,是远远不够的。这个工作,需要前瞻性,正确安排适当的激励机制:开发者的访问和策略。想想你想让你的生态系统的经验类型(以及你想直接拥有哪些经验)。然后构建 API 以启用搜索功能。配置您的 API,文档和策略,以指导开发人员提升价值链。并使您的核心产品体验更好,以便不需要替代核心体验。

相反,不要为您必须拥有的内部功能提供 API。如果您提供的 API 能够为产品的核心方面提供支持,那么您可以有效地指导您的开发人员基础构建相同的服务或其相近的衍生产品 ; 设想一下如果 Twitter 从未公开提供家庭时间线的 API。最后,当您在生态系统中找到那些集成重点,说明您希望看到由开发者社区解决的水印使用案例——为这些 App 擂鼓助威!让生态系统知道这是所有其他应用程序应该追求的质量水平。演示如何照顾这些玩家:加快推广点击水印、共同开拓市场机会、增加 API 访问权限等。在那一天到来之际,如果有一个平台的所有参与者都信任,透明清晰的沟通,良好的期望和互惠利益——一个令人难以置信的生态系统能够蓬勃发展。看起来没有比 Stripe、Twilio 和其他公司看上去多么强大的公司。只要放眼乾坤,这是一个有意义的投资,你必须致力于长期发展。

从一个更广泛的角度来看,API 使各种“混搭”的网络服务成为了可能,开发者通过混搭来自 Google、Facebook 或 Twitter 的 API 来创造全新的应用和服务。在许多方面,可以说是主流服务 API 的广泛应用才使现代网络体验成为可能。

一个 API 现在可用,并不意味着将来也可用。以 Twitter 为例,一年以前就以限制第三方应用使用其 API 而臭名昭著,这种做法杀死了所有的第三方 Twitter 客户端,让用户只能使用 Twitter 自家的网站和应用,Twitter 从中展示广告赚钱。Twitter 称自己坚持这么做是为了保持统一的 Twitter 用户体验。

有些公司可能会关闭服务和 API,例如 Google 就总是把一些见不到利润的服务关闭,最近的例子是 Google Reader,如果你的应用依赖这些 API 来运行的话,就会随之一同出现问题。

虽然 API 的世界并不完美,但依然阻止不了开发者对其的热情,也阻止不了由其促成的各种多样化应用和服务。


感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-11-21 16:342332
用户头像

发布了 370 篇内容, 共 171.5 次阅读, 收获喜欢 940 次。

关注

评论

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

鸿蒙轻内核M核源码分析:数据结构之任务就绪队列

华为云开发者联盟

鸿蒙 数据结构 数组 双向循环链表 任务就绪队列

iOS 面试策略之系统框架-网络、推送与数据处理

iOSer

ios

详解支撑7亿用户搜索的百度图片处理收录中台

百度Geek说

中台 搜索 图片处理

手撕友商7nm FPGA?英特尔“亲儿子”上阵

E科讯

2021年5月墨天轮国产数据库排行榜:十强榜单固若金汤

墨天轮

数据库 腾讯云 阿里云 国产化 dba

数字化转型助推,200亿元数据治理市场空间充满想象

DT极客

🕋【Redis干货领域】从底层彻底吃透AOF重写(原理篇)

洛神灬殇

redis持久化 aof Redis 核心技术与实战 5月日更

话题讨论|程序员在520最想收到什么礼物?

饭饭

程序员 恋爱 520 单身

英特尔Agilex FPGA大规模量产出货,正面硬杠赛灵思

E科讯

领域驱动设计(DDD)

码语者

DDD

Sentinel在docker中获取CPU利用率的一个BUG

捉虫大师

Java Docker sentinel

牛!马士兵亲自教授坦克大战+精通23种设计模式,视频+笔记+源码

Java架构追梦

Java 架构 面试 23种设计模式 坦克大战

英特尔PK赛灵思,完美胜出!Agilex™ FPGA迎来大规模量产

E科讯

音视频开发视频和视频帧:ffmpeg的RTMP推流

赖猫

音视频 ffmpeg 推流 RTMP RTSP

百亿级图数据在快手安全情报的应用与挑战

NebulaGraph

图数据库 大厂实践

云时代的数据之约

BinTools图尔兹

数据库 云计算 运维 云服务 dba

面试官:啥是请求重放呀?

why技术

Java

Springboot结合Netty实战聊天系统

Damon

音视频

如何模拟弱网环境?

运维研习社

Linux 运维 网络 5月日更

ShardingSphere 源码

云淡风轻

ShardingSphere

实践解析 | 如何用 OpenGL 实现跨平台应用高效渲染

拍乐云Pano

Android开发

如何自学 Java ?不报班只白嫖行不行?

Java架构师迁哥

模块四作业

Chris Cheng

架构实战营

消费者剩余:你愿意花多少钱买一件东西?

石云升

创业 产品 职场经验 5月日更

Redis后端之Redis持久化

赖猫

redis 后端 LinuxC/C++

话题讨论|做程序员五年后是什么样子?

饭饭

程序员 职业规划 发展现状 内卷 IT行业

前端领域的数据状态统一管理机制

鲸品堂

大前端 数据 流程图 state

Nextcloud一站式体验

白粥

NAS Nextcloud

华为发布HarmonyOS Connect品牌升级计划 帮伙伴做好产品、卖好产品、运营好产品

科技汇

快时代的知识形态

Ryan Zheng

Rust从0到1-集合-Hash Map

rust hashmap 集合 Collections hash map

从两个风格迥异的API平台说开去_语言 & 开发_刘志勇_InfoQ精选文章