Amazon提供API接入 開發者可分享銷售收益

應用市場是一件讓所有人頭疼的事。除了蘋果和 Google，大家都在拼命地獲取使用者和推銷平臺，當然還有更重要的——討好和留住開發者。

Amazon 顯然正在朝著這些方向努力，尤其是在為開發者提供福利這事上。這家公司在週二釋出了名為Mobile Associates API的計劃，以為開發者提供在應用內購買 Amazon 平臺實體貨物的方式使雙方獲利。

利益分配模式很簡單：開發者在應用中新增購買 Amazon.com 貨品的功能（在使用者登入 Amazon 賬號的情況下）。開發者可以從通過該功能產生的任何交易中分到最多 6% 的利益，Amazon 收得餘下部分。

假設我是一款開發運動遊戲軟體的開發者，使用者就可以通過我的遊戲在 Amazon.com 上用著名的一鍵下單方式買得一顆實體足球。那麼我和 Amazon 之間就按照上述的方式分配這筆交易所帶來的收入。

譯文來源：36氪
資訊來源：allthingsd.com

什麼是API

API（Application Programming Interface）提供了對某個問題的抽象，以及客戶與解決該問題的軟體元件之間進行互動的方式。元件本身通常以軟體類庫形式分發，它們可以在多個應用程式中使用。概括地說，API定義了一些可複用的模組，使得各個模組化功能塊可以嵌入到終端使用者的應用程式中去。

現代應用程式通常都是基於很多API建立起來的，而這些API往往又依賴於其他API。如圖1-1中示例應用程式所示，該應用程式用到了3個類庫（1、2、3）的API，而這3個API中有2個又用到了另兩個類庫（4和5）。舉例來說，瀏覽圖片的應用程式可能會用到載入GIF圖片的API，而該API本身則可能又依賴更底層的壓縮或解壓縮資料的API。

圖字翻譯：
Application Code：應用程式程式碼
Library：類庫

圖1-1 從層次化API中呼叫例程的應用程式。每個方框代表一個軟體類庫，灰色部分表示其公共介面，對於類庫而言即是其API，白色部分表示隱藏在API後面的具體實現。

API開發在現代軟體開發中隨處可見，其目的是為某個元件的功能提供一個邏輯介面，同時隱藏該模組內部的實現細節。舉例來說，我們用來讀取GIF圖片的API可能僅僅提供一個LoadImage()方法，後者接收一個檔名作為引數，並返回一個2維的畫素陣列。所有檔案格式和資料壓縮的細節全部隱藏在這個看似簡單的介面之下。這個概念也在圖1-1中進行了說明，即客戶端程式碼只能夠通過該API的公有介面訪問。API公有介面如圖1-1中每個方框頂部的灰色區域所示。

為什麼使用API

如果你正在編寫供其他開發人員使用的模組，不管他們是公司裡的其他工程師還是外部客戶，比較明智的辦法是構建API來讓他們訪問這些功能。這麼做會帶來以下好處。

• 隱藏實現。通過隱藏模組內部實現的細節，開發人員就可以在未來的某個時間自由修改模組的實現而不給使用者造成重大影響。如若不然，會導致以下結果：（1）程式碼的更新將會受到限制；（2）使用者只有重寫程式碼才能使用新版本的程式庫。如果總是讓使用者不停地更新軟體版本，他們很可能不願再做更新，或者乾脆棄用，另外尋找不需要太多維護工作的API。因此，優秀的API設計對業務或專案成功至關重要。

• 延長壽命。隨著使用時間增長，那些公開了實現細節的系統的內部程式碼會變得錯綜複雜，系統的各個部分要依賴其他部分的內部實現細節。因此，系統將會變得脆弱、死板、不可移植且粘滯性高（Martin，2000）。如此一來，公司為了改善這些程式碼，就不得不花費大量人力財力，甚至推倒重寫。事先花工夫做好API設計，而後維護好該設計以保證一致性，軟體壽命就能延長，從長遠看也能節省花費。在第4章的前面部分，我們會深入討論該問題。

• 促進模組化。 API通常用來完成一項具體的任務或用例。因此，API定義了一組具有一致目的的模組化的功能集。在大量API基礎之上開發的應用，其結構將降低耦合而更加模組化，每一個模組的行為都不依賴其他模組的內部細節。

• 減少程式碼重複。程式碼重複是軟體工程中最惡劣的行為之一，任何時候都要避免犯此類錯誤。通過把所有的程式碼邏輯置於一個嚴格的介面之後，讓所有客戶使用這個介面，就能將程式的某種行為統一處理。這樣做意味著只需更新一處程式碼就可以改變向所有客戶提供的API的行為。這樣有助於消除程式碼中所有重複的實現。事實上很多的API就是這樣實現的，人們首先發現有重複的程式碼，然後製作統一的介面取代這些重複程式碼，於是就產生了API。這是一件好事。

• 消除硬編碼負擔。很多程式可能包含硬編碼的值，並在整個程式碼中不斷複製。例如，在需要寫日誌檔案的地方就使用具體的檔名“myprogram.log”。我們可以使用API來提供這些資訊，而不用在整個程式碼層面複製這些常量，例如，使用GetLogFilename() API呼叫代替硬編碼的“myprogram.log”字串。

• 易於改變實現。如果將所有的實現細節隱藏在公共介面背後，就可以在不影響任何依賴此API程式碼的情況下改變其內部的實現細節。例如，可以將原本使用std::string解析檔案的方式變為分配、釋放、再分配char*緩衝區的方式。

• 易於優化。成功隱藏了實現細節後，在優化API的效能時就不用操心更改客戶端程式碼。例如，可以利用加設快取的方案優化某個計算密集型的方法。之所以這樣做是因為所有讀寫潛在資料的操作都是通過該API進行的，因此該API更確切地知道何時快取中的結果無效並且需要重新計算結果。

以上內容選自《C++ API設計》