文/钱宏武 现在做任何应用，已经到了言必称API的地步。很久之前，我写过一篇类似的文章来说明Open API是一个未来的趋势，而当时同时流行着一个概念叫Web 3.0。我曾经尝试过Open API很多次，发现这个东西难度之高远远超过自己的能力。 第一次用API的方式写东西是在2004年，当时我所在的社区刚刚稳定，便尝试去做一些API，来让其他的程序调用接口。结果发现想用比较简单的规则组合来完成非常复杂的应用，这其中，颗粒度的把握，根本就是无从下手。就像编程语言中，制定几个基础函数来构架整个语言体系，看着简单，但能力不够还真是不行。这次尝试以放弃告终。 第二次，在2006年，再次尝试用上面的方式，给社区加Cache。但发现在考虑效率和功能点的时候，还要兼顾API的颗粒度，这个三位一体的维度实在无法把握，又放弃了。 第三次是在2009年，当时自己创业做一个机器人系统，协议看了很多，时间也有，而且不赶进度，这次该可以做API了吧。可发现和上次一样，颗粒度还是很难把握。以封装函数为例，封装太大，很多产品的功能点无法实现；封装太小，外部调用的时候，开发又过于繁复。自己尝试后，开发效率和运行效率都低到无法忍受，还是放弃了。 第四次，也就是去年，需要做一个后台统计。当时想不过做一个通用的API，场景功能也简单，该没问题了吧。然而做了一周就发现，这个API和产品需求之间存在一个功能点，无论怎么做，通过API实现后效率都极低。研究一下架构设计，如果要实现这个功能，整个架构不得不整体推倒重来，这仅仅为了实现这个功能点(当然前提需要保证效率)。但在重新架构之后，也无法保证是否还有别的功能会出现问题，一周的东西等于白做了。最后还是放弃了从API的角度来约束整个结构，实现所有产品功能的想法。 四次失败后，我想了很长的时间其中的原因。前三次可以用经验不足来形容，但第四次的失败，我必须承认能力实在不够，起码现阶段是不够的。分析后，我得出以下几点。 首先，整个产品的熟悉和稳定。在产品没有稳定下来之前，就把API规定好，这其实有很大风险和不确定性。毕竟功能最小的原子操作你都不确定，更上面一层的API的颗粒度更是无从把握。 其次，产品架构的安全和效率。这点要求在Open API之前，整体架构已经很健全了。毕竟API不仅是考虑实现，还必须兼顾效率，特别是互联网应用。这需要开发人员很清楚如何在安全、功能、效率之间保持平衡。如果一开始就考虑这些东西，需要做到三者兼顾。 最后，考虑对开发效率的影响。特别是早期开发的时候，对于项目管理者，必须做到开发的灵活可控，并且通过调度做到平衡。而当API的颗粒度设置完毕后，事实上，人为加大了产品开发中，灵活控制的难度。而一旦发现颗粒度有问题，对整体结构伤害将非常大，使开发的效率直降得非常厉害，这个对我有切身感受。 我现在理解，对于API来说，更多的时候是一种技术进攻的策略，所谓走出去，给大众使用，但就像当年做操作系统，是一个需要天才和好运的东西。一旦做好了，固然是完美无缺的东西，但因为难度极大，一丝一毫的差错，都会引起项目的极大风险。 当然这些都和个人能力有关系，能力足够强的人是能做出来的，但我不是盖茨，也比不了Twitter、Foursqure的天才架构师们。用API来开发互联网项目，现阶段我还是做不到的。个人的经验总结下来就是，“珍惜生命，远离API”。 作者介绍：钱宏武，现任职盛大创新院，原搜狐互动产品开发部主管，资深互联网社区架构师，垂直搜索领域专家。 (本文选自《程序员》杂志11年06期，更多精彩内容敬请关注06期杂志) 《程序员》6期精彩内容：移动应用的成功法则 《程序员》杂志订阅