API 已死，API 长存
Netflix 的 API 曾被称为网络上最成功的 API 之一，支持双向读/写访问，而且第三方软件不用密码就可获得 OAuth 用户认证。公司之前透露，每天外部调用 Netflix API 的次数达 20 亿次一天。用户群体数量十分庞大。
但最近 Netflix 公布几个决定，表明公司未来将停止在 API 方面的投入，前后变化之大，让人惊诧：
我们不再发放新的、公开的 API 秘钥；
不再接受新的 API 请求，不再提供测试环境；
我们将关掉开发者论坛；
我们将撤销 OData 目录。
以上决定不影响现有的 API，Netflix 鼓励开发者到 StackOverflow 继续讨论和 Netflix API 相关的话题。但结果已经很明显，以后再没有开发者能够通过调用 Netflix API 来开发形态各异的应用。而对于依靠 API 来生存的 IFTTT 等应用来说，Twitter、Netflix 限制 API 的举动，多多少少会激起他们恐慌的情绪。
于是，API 工具公司 Runscope 联合创始人 John Sheehan 写了一篇文章，标题为《API 已死，API 长存》，说明公开 API 受限的现状，也分析了为何如今公司们纷纷停止支持 API 的原因：
从短期来看，开发者的兴趣，以及 API 提供者的兴趣并不一致。
之前许多第三方 Twitter 客户端，为了吸引用户，提供了 Twitter 不再使用的“RT”语法，而这些客户端当然也不会帮 Twitter 显示广告。对于 Twitter 而言，开放 API 给第三方使用，最直接的后果是：让 Twitter 的内容无处不在。
但 Sheehan 认为，目前 Twitter 已经不在意这一点了——Twitter 最近发布了针对广告商的 API。而在近期举行的西南偏南大会（SXSW）上，负责 Twitter 全球营收的 Adam Bain 表示，广告商对广告 API 系统的反应积极
如果一个产品非常依赖 API 的调用，那么它的命运将被 Twitter 和 Netflix 等 API 供应商扼住。目前，有什么好方法，能让依赖 API 产品规避未来的风险吗？Sheehan 提出了三项原则：
- 不可白吃白喝。这条原则的意思是，API 提供商不会任由开发者随意利用自己的资源，因此开发者应适当返回一些资源给 API 供应商，达到利益上的均衡，否则会将产品置于危险的境地。
- 不可放弃与人对话。这个原则的意思是，开发者必须和 API 提供商建立关系，这是不可逃避的责任。如果不能与某些人牵上线，那么这就是开发者不应该再使用 API 的理由。
- 必须监控一切。这个原则的意思是，使用 API，意味着应用的一部分在别人的服务器上运行。因此严格要求，监控一切，以防出现错误——在用户知道错误之前，采取预防措施。
以上三个原则，可看出前提是“资源互换”。不过，对于大公司而言，开不开放 API，都是基于商业利益的考量。开发者要如何满足“大公司”的胃口呢？
也许，相对于发展已经较为成熟的互联网行业，已经渡过那段通过 API 笼络开发者，扩大用户群体的阶段。毕竟开放 API 相当于开放资源。不过，这不意味着 API 会就此消亡，在正在勃兴的开源硬件创业潮中，通过开放 API，笼络同盟，已经是惯常的做法。之前我提过 Spark 这款智能灯具：
在 Kickstarter 上，智能灯座项目 Spark 反其道而行之，强调开放性。它开放 RESTful API 接口，能够与其它应用，硬件相连。理论上，开发者可以为它开发电脑上的软件，甚至可以通过 Twitter 来控制 Spark 的开关等等。实际上，内置了温度传感器、加速度计、磁性开关，能与 Wi-Fi 相连的实体版“IFTTT” Twine，以及相当受关注的智能手表 Pebble，已经能与 Spark 相连。
而国内，原本封闭的互联网大公司也越来越倾向于开放。比如腾讯推出的微信，自公众账号上线以来，在微信上创业的人都十分关心微信开放 API 的进度。
而在微信上，API 也成为一场生意。武汉大学谢梦非推出的“武大助手”公众账号，内置了许多生活查询功能，比如查看课表、成绩、附近厕所、校花校草等等。这些数据都通过 API，从网站或者其它应用中获取——比如找厕所这个功能，谢梦非就说是利用“噢粑粑”的数据。
百度最近主推“应用内搜索”，也开始拥抱 API 任何人通过百度 App 来搜索视频、地图、音乐等方面的信息，都能够直接调用本地的应用。比如搜索“我是歌手”第八期后，就能够直接在爱奇艺上直接观看。
当然无论是微信，还是百度 App，它们都属于移动阵营。若移动行业发展成熟，是否也会出现限制 API 的情形？也许，从现在开始，开发者们就应该听一听 Sheehan 的建议。
题图来自 electronicintifada
