编者按：本文作者为Joseph Puopolo ，创业公司Printchomp创始人。在他看来，很多年轻的创业公司没有自己双脚站立的能力，API调用已经成为了一个拐杖，代替了自己生成数据的能力。因为API变更和服务条款变更而被灭掉或被打击得奄奄一息的公司有很多，Twitter的API变更就是一次警醒，这篇文章的目的在于提醒寄居蟹模式的公司们：

　　我一直惊讶于有这么多公司会在API调用的基础上做应用并冒着大的商业风险去建立他们的公司。无数的app特别是社交app，将其他系统中的数据抓取过来然后重新在自己系统中显示的模式在过去两年内突然流行起来。尽管API已经在广泛使用，但我依旧认为创业公司的创始人一直对这项业务的风险轻描淡写了。

　　这一风险是很明显的，如果数据干涸，你的业务也会一样。对于那些已经被做出来的大部分基于API调用的app来说，可以考虑信息流不再了之后会发生什么。那些提供API的公司不一定是消失了，但它绝对会成为那个改变游戏规则的人。Twitter的API变化就是一次警告和重要的提醒。无数的第三方Twitter 应用都发现，在最新的1.1 API协议发布后，重要的数据流会停止或大大变缓，而他们的辛勤工作都化为乌有。有些人会将这件事的责任归到Twitter的身上，并埋怨他们怎么敢关掉他们社区的信息流。但我认为这件事很多责任应该由开发者承担，因为他们明知自己无法控制，还将这个生态系统作为基础。

　　在Twitter的开发者博客中，Michael Sippey直接引用了两个例子：Tweetbot和Echofon。Sippey说到，“在接近18个月的时间里，我们指导过开发者让他们不要建立那种模仿或复制Twitter主流客户体验的客户端应用。重申我上一篇文章所写的，这种指导意见依旧适用。”我并不是想在这为他所说的做解析，而是对那些将业务建立在API上的创业公司发出警醒。

　　如果你的创业公司有因为服务条款变动或API变动被割喉的可能，你就不应该将公司固有的风险给掩盖起来。在将风险从你公司移出的同时，你同时也应该考虑你能给予用户的真正的价值是什么。在很多情况下(特别是在社交应用的例子中)，一些app不过是在Twitter或Facebook信息的基础上多批了一件新界面的外衣而已。

　　而与此相反，也有一些公司很惊艳地，在成为生态系统一部分的同时还让他们的功能能无缝衔接更多的应用。这里面最好的例子当数 37 Signals 。他们建立并整合了很多其他有用的应用。他们允许那些至关重要的商业信息在不同的系统间自由流通。对于其他公司或应用来说，出现麻烦是因为他们仅仅通过一个API去依赖别人的生态系统，将别人生成的数据放到自己的系统上。

　　或许我提出的建议会有点过时：你的应用需要在使用API调用及随后的数据之外，提供一些额外的价值。你应该创造自己的进程，让用户在你的系统上贡献数据，并鼓励他们在你的系统中(通过你系统中的个人账号)成为活跃用户。你的系统需要用自己的双脚站立。对于很多年轻的创业公司来说，API调用已经成为了一副拐杖，代替了自己生成数据的能力。

　　对于很多创业者来说，想创造人们感兴趣并使用的产品还需要很多的灵魂搜索。仅仅因为你可以做一个API调用并贴上一个看起来新一些的用户界面，并不能成就一桩真正的生意。