简单地构建一个API是不够的。如果在发布API之前不能“先自己试试”，那么结局就是失败。Zachary Flower详细解释了个中原因。创业公司的开发生命周期必然充满妥协。有太多东西需要完成，但是没有足够的资源保证所有东西都“正确”完成，因此开发人员在恰当的时候必须妥协。不幸的是，为产品构建API与其说是技术决策，不如定义成业务决策更为贴切，这也正是需要妥协的地方。

为已有产品构建API的挑战是，业务需求总是最重要的。为了跟上业务需求的脚步，我们通常被强迫在产品质量上作出让步，这在创业公司应用开发过程中很常见，也绝对是API开发的最差方式。

开发API时最重要的一件事是就是使用它。“Dogfooding”是创业论坛里的流行词汇，用来描述企业规律地使用自己的产品，从而更好服务客户的行为。在创建API时，能够“先自己试试”极其重要，因为其向开发人员提供了一种方式来集成业务的核心功能到自己的产品里。如果这样，或者作为主要产品的一部分，API无法正常工作，那么开发人员，及其用户，注定无法获得良好的用户体验。这会让所有人都感觉很糟糕。

挑战代码基

如果在构建API时不先自己试试，那么可能最终需要管理两个单独的，大部分功能一样的代码基。第一个代码基，主要产品，是大部分开发活动发生的地方。因此，它比第二个代码基，API，更加清晰并且功能更为丰富。

被称为“第二个”代码基的API，会很快成为无主代码。它的更新很繁琐，和实际开发相比更像数据处理的工作，因为大部分工作是从“主要”代码基里拷贝方法出来。因为其特性和bug修复晚于主要产品，这会使得用户——至少坚持在使用的消费者——感到上当受骗，甚至可能感到被开发人员背叛了。

API开发会最终延期，甚至可能完全终止，从而保证团队将更多的资源关注于主要产品上。

正确还是完全不正确

当构建API时，一个很好的规则就是，如果还没有准备好重写所有后台代码从而自己试试API，那么最好避免开发API。要像思考任何新产品那样仔细全面地思考开发API的决策。这样，你才能高效投入到构建两个新产品里，因为不能不使用API。

当API是你自己产品的正式后台时，那么很容易保持代码DRY——不重复自己。特性直接为API而开发，这使得可以立即向客户发布特性。这也使得在将主要产品发布给API用户之前测试这些新特性容易得多。当制造者同时也是产品的用户时，那么所有API上存在的问题都会得到极大的重视。Bug会被立即修复，因为它们影响到所有人。

随着开发人员越来越频繁地使用第三方API，我发现大家都能够指出哪些是核心产品的核心部分，哪些是后来添加的东西。不需要专家就能构建出质量良好的产品，开发人员会主动解决使用产品直接会遇到的问题：这在后来开发的API里就缺失这样的关注。