簡單地構(gòu)建一個API是不夠的。如果在發(fā)布API之前不能“先自己試試”，那么結(jié)局就是失敗。Zachary Flower詳細解釋了個中原因。創(chuàng)業(yè)公司的開發(fā)生命周期必然充滿妥協(xié)。有太多東西需要完成，但是沒有足夠的資源保證所有東西都“正確”完成，因此開發(fā)人員在恰當(dāng)?shù)臅r候必須妥協(xié)。不幸的是，為產(chǎn)品構(gòu)建API與其說是技術(shù)決策，不如定義成業(yè)務(wù)決策更為貼切，這也正是需要妥協(xié)的地方。

為已有產(chǎn)品構(gòu)建API的挑戰(zhàn)是，業(yè)務(wù)需求總是最重要的。為了跟上業(yè)務(wù)需求的腳步，我們通常被強迫在產(chǎn)品質(zhì)量上作出讓步，這在創(chuàng)業(yè)公司應(yīng)用開發(fā)過程中很常見，也絕對是API開發(fā)的最差方式。

開發(fā)API時最重要的一件事是就是使用它。“Dogfooding”是創(chuàng)業(yè)論壇里的流行詞匯，用來描述企業(yè)規(guī)律地使用自己的產(chǎn)品，從而更好服務(wù)客戶的行為。在創(chuàng)建API時，能夠“先自己試試”極其重要，因為其向開發(fā)人員提供了一種方式來集成業(yè)務(wù)的核心功能到自己的產(chǎn)品里。如果這樣，或者作為主要產(chǎn)品的一部分，API無法正常工作，那么開發(fā)人員，及其用戶，注定無法獲得良好的用戶體驗。這會讓所有人都感覺很糟糕。

如果在構(gòu)建API時不先自己試試，那么可能最終需要管理兩個單獨的，大部分功能一樣的代碼基。第一個代碼基，主要產(chǎn)品，是大部分開發(fā)活動發(fā)生的地方。因此，它比第二個代碼基，API，更加清晰并且功能更為豐富。

被稱為“第二個”代碼基的API，會很快成為無主代碼。它的更新很繁瑣，和實際開發(fā)相比更像數(shù)據(jù)處理的工作，因為大部分工作是從“主要”代碼基里拷貝方法出來。因為其特性和bug修復(fù)晚于主要產(chǎn)品，這會使得用戶——至少堅持在使用的消費者——感到上當(dāng)受騙，甚至可能感到被開發(fā)人員背叛了。

API開發(fā)會最終延期，甚至可能完全終止，從而保證團隊將更多的資源關(guān)注于主要產(chǎn)品上。

當(dāng)構(gòu)建API時，一個很好的規(guī)則就是，如果還沒有準備好重寫所有后臺代碼從而自己試試API，那么最好避免開發(fā)API。要像思考任何新產(chǎn)品那樣仔細全面地思考開發(fā)API的決策。這樣，你才能高效投入到構(gòu)建兩個新產(chǎn)品里，因為不能不使用API。

當(dāng)API是你自己產(chǎn)品的正式后臺時，那么很容易保持代碼DRY——不重復(fù)自己。特性直接為API而開發(fā)，這使得可以立即向客戶發(fā)布特性。這也使得在將主要產(chǎn)品發(fā)布給API用戶之前測試這些新特性容易得多。當(dāng)制造者同時也是產(chǎn)品的用戶時，那么所有API上存在的問題都會得到極大的重視。Bug會被立即修復(fù)，因為它們影響到所有人。

隨著開發(fā)人員越來越頻繁地使用第三方API，我發(fā)現(xiàn)大家都能夠指出哪些是核心產(chǎn)品的核心部分，哪些是后來添加的東西。不需要專家就能構(gòu)建出質(zhì)量良好的產(chǎn)品，開發(fā)人員會主動解決使用產(chǎn)品直接會遇到的問題：這在后來開發(fā)的API里就缺失這樣的關(guān)注。