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

了解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 API和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的世界并不完美，但依然阻止不了开发者对其的热情，也阻止不了由其促成的各种多样化应用和服务。