從商業角度探討API設計

　　爲Web設計、實現和維護API不只僅是一項挑戰；對不少公司來講，這是一項勢在必行的任務。本系列將帶領讀者走過一段旅程，從爲API肯定業務用例到設計方法論，解決實現難題，並從長遠的角度看待在Web上維護公共API。沿途將會有對有影響力的人物的訪談，甚至還有API及相關主題的推薦閱讀清單。

　　現在，API已經成爲了每一個重要信息技術趨勢的核心內容。移動設計、雲計算、物聯網、大數據及社交網絡等應用都依賴於一個基於web的界面與它們的分佈式組件進行鏈接，爲全球範圍內的各個商業領域提供具備創新性和顛覆性的解決方法。智能電網（Smart grid）技術改變了能源行業的形態，聯網汽車（Connected Car）解決方案則被視爲自動汽車行業中的關鍵因素，亞馬遜使得每一個所接觸的行業都產生了具大變化。在全部這些例子中，API的使用既是催化劑，也是促成這一成果的主要力量。

　　因爲API對於商業的巨大影響，所以有關「API的商機」的各類文章也是層出不窮。在開放性的互聯網上，使用API做爲一種外部頻道進行創新及盈利已經成爲一種獨特的商業模型。在由Kin Lane所建立的API傳道（Evangelist）網站中能夠找到關於這一話題很是全面的信息，Mehdi Medjaoui則在最近的一篇帖子中用精練的語言對此進行了總結。而後，在跨科技領域的API應用範圍內，開放式API模型僅僅表現出其實用性的冰山一角。實際上，Web API的主要能力尚未從各類使用API實現的解決方案中被髮掘出來。從這種意義上說，API的商機自己就是一種商業模式。

　　本文將從商業角度對API進行全面的講解分析，不管它是不是開放式而且公開發布的。我會談到嘗試用API爲你帶來商業價值的重要性、分析在其中應該使用的數據類型、並學習Aamzon及Twilio的成功經驗。但願這些內容可以有助於你打造有用的、而且可用的API。

　　評估API的商業價值

　　API的通用商業價值是能夠進行評估的。一切從數據出發，許多公司及組織將他們的數據視爲一種負擔，畢竟服務器和存儲方案的價格不菲。但在現在這個愈來愈趨向於電子化的世界中，很顯然，數據也是一種寶貴的資產。數據提供了各類寶貴的客戶資料，它可以產生可辨別的商機與新的收益方式。「大數據」狂潮正是追求經過海量數據的分析處理電子中的混亂信息。即將到來的物聯網（IoT）爆炸將使數據的規模呈現指數級的增加，所以對各個公司來講，對於數據進行正確的分析就變得相當重要。

　　對於一家公司來講，數據究竟是一種資產，仍是一種負擔，是取決於如下三個方面的：即數據的可訪問性、準確性和可應用性。每一個Web API都在某種程度上提供了某些數據的可用性，而有價值的API則爲公司的核心商業數據提供準確的數據。這使得公司可以達到一種我稱之爲「Data-Enabled Disruption」的迭代發展模式，在下文中我會爲這種模式作出解釋。此外，在決定應該由API暴露哪些數據及服務時，以及如何實現這些API時，這三個方面的數據屬性也提供了一種有效的方法論。

數據可應用性	這些數據是否有助於個人商業目標決策？ 這些數據是否可以爲個人業務帶來獨特的價值？ 若是我將這些數據公開化，是否能產生某些商機？
數據準確性	當前提供的數據時效性如何？ 數據的來源是否可靠？ 數據是否由指望中的用戶所使用？是否用於正確的目的？
數據可訪問性	哪些數據是能夠由編程方式獲取的？ 有哪些不一樣的方法能夠獲取這些數據？ 開發者建立使用這些數據的應用難度有多大？ 數據訪問的規模可否知足客戶的需求？

　　若是從API的角度對這套方法論進行驗證，那麼能夠將數據的這三種屬性合併爲API的兩種屬性：

1. 「實用的API」提供準確與合適的數據
2. 「可用的API」提供可訪問的數據

　　顯然，最有價值的API應當知足實用與可用兩個條件。不過，爲了更進一步定義這些API屬性，讓咱們分別來進行一下分析。

　　實用的API

　　在開發API時，人們最多見的一種錯誤就是認爲全部的數據都是有用的。有一種流傳甚廣的奇談是這麼說的：一旦你拿出這些數據，神奇的開發者們就會出如今你面前，他們會撒下一些具備魔力的粉末，讓你的收益獲得增加、涌現各類創新的想法、並打通各類商業渠道。但僅僅使用API和開放數據是不足實現這幾點的。正是這種「媒體即訊息」的想法形成了過去十多年間在企業整合這一領域中出現了大量失敗的SOA嘗試。某家超大型企業曾經花費了5千萬美圓以上的資金企圖打造一個SOA及私有云的項目。而當我問及他們打算爲哪些客戶提供什麼樣的服務時，他們馬上就啞口無言了，由於他們只關心如何打造基礎設施。毫無疑問，這個項目最終失敗了。

　　從好的方面來講，若是可以使用正確的API公開正確的數據，那麼就可以實現收益的增加與創新的進步。Google Maps利用Google壓倒性的佔有率所提供的基於API的服務，正好填補了市場在這方面的空白。因爲這一服務至關便利，所以Google能夠將它做爲商業產品收取大量費用。因爲API的存在，Google Maps也成爲了早期iOS平臺上的常駐應用，而蘋果本身推出的替代品在一開始的反響就至關差，這反而突顯了Google Maps的價值。由Facebook與Twitter領銜的社交網絡平臺的發展與成功也離不開API的應用，正是後者促進了他們的web連接數目與移動平臺上的應用實現。實用的API甚至對聯邦競選活動產生了深遠的影響。

　　Amazon的API故事

　　正如我在文章開頭所說的同樣，企業從API中得到商業成功的潛力遠遠大於開放API在表面上的能力。Amazon就充分利用了這種潛力，其實它們的API最初只是在公司內部進行使用。API爲Amazon所帶來的這種長遠的成功在任何一個行業中都找不出類似的案例。Amazon爲使用其API的客戶提供了寶貴的經驗，幫助這些企業使用它們的API得到商業上的成功。

　　Amazon爲咱們所上的第一堂課，也是最爲明顯的一堂課，就是它是怎樣將API設計爲產品與解決方案的構造塊的。Brad Stone在由他編寫的書籍中專門用了一章的篇幅來描述Amazon是怎樣將基礎API發展爲它的技術航母的。Kin Lane也對Jeff Bezos（Amazon的CEO）是怎樣從執拗的陳舊觀念中慢慢轉變，讓Amazon最終提供編程式訪問能力的過程進行了精彩的總結。按照這些報告及一些其它資料所說，產品經理必須指出他們的提案中的商業價值的最小公分母。隨後技術團隊就會利用這些原始數據建立API，將這些商業價值提供給其餘開發者，讓他們繼續建立整個方案中剩餘的部分。背後的邏輯在於這些商業價值的增加可以直接使用，而且可以很是容易地進行結合，以進行將來的產品開發。這就是爲何Amazon Web Services可以如此迅速地發佈及改善：Amazon對它們的基礎設施服務都進行了API化，從而優化了擴展基礎設施能力的過程。AWS的產生過程就是將這些內部功能轉化爲外部產品。正如你所見，Amazon不只僅保證了他們所提供的API提供了有用的數據，而是走得更遠，他們將這一原則進行了倒轉，保證了整個解決方案中的每一份數據都可以由API方式進行提供。

　　Amazon在API方面的另外一個例子是它如何使用基於API的方式進行有價值數據的收集、分析、改善以及分佈的。當早期的Amazon還以在線書籍的銷售爲主營業務時，Jeff Bezos對於Amazon的核心價值觀念就有了清晰的預期：「咱們不是經過銷售盈利，而是經過幫助客戶進行採購決策而盈利。」他始終保持公司的運營與這一核心價值觀相一致，從而產生了策略方向的各類改變，例如提供個性化及擴展頻道等舉措。實際上，從以上核心價值觀中就能夠看到，正是這些適用的、準確的、而且可訪問的數據爲客戶的決策做出了引導，讓Amazon一步步走向成功，而不是靠着在線圖書或其它商品的銷售得到的成功。在Amazon，正是API將數據進行不斷積累與改進，這一週期性的過程刺激了Amazon的成長。我將這個360度的週期稱之爲數據革新「Data-Enabled Disruption（DED）」，下圖是我對它的總結：

　　DED的成功運用，使得Amazon得以擊敗無數競爭對手。因爲在整個數據生命週期的每一步都應用了API，所以Amazon可以持續地改進數據的準確性、適用性及可訪問性。

　　咱們最後將學習Amazon是怎樣在公司的戰術產出和策略定位之間進行平衡的。自從Jeff Bezos認識到萬維網的潛力，並制定出「提供全部商品的商店」這一願景以後，他就很是清楚地認識到這種平衡的重要性。Bezos認識到他先要從一個較小的目標開始，通過對市場進行一番分析以後，他認準了在線圖片銷售這一領域，它的發展時機已經成熟，而且供應鏈也十分理想。在隨後的發展中一方面保證快速的執行，一方面始終不忘對將來的願景設計，這種齊頭並進的發展理念已經成爲了Amazon文化的一條根深蒂固的宗旨。每一個解決方案既要爲公司產生價值，也要爲將來的發展鋪好基石。基於API的交付方式就是實現這種原則的一種理想的方式，由於API不只可以服務於新的應用與服務，也可以爲將來的各類用例打好基礎。這種迭代式發展的方法論促進了亞馬遜業務的不斷髮展（見下圖的說明）。

　　圖片中的每一個服務都對應着一套外部的API，同時，每套API都是創建於已經完成的API基礎之上的。任何一家打算縱向或橫向進行業務擴展的公司，均可以認真參考一下Amazon是如何打造一套有用的API的方法：持續地收集和獲取可用的數據、使用API做爲這些數據的通用訪問點、只交付短時間內有用的數據，同時兼顧長期的發展計劃，以此做爲公司的競爭力進行不斷擴展。

　　可用的API及API設計的重要性

　　儘管Amazon在這方面取得了使人矚目的成就，而且API在公司的成功中扮演着重要的角色，但Amazon的API仍然沒有被公認爲設計最優秀、使用最簡單的API。隨着API數量的爆炸性增加，而且對於API的必要性的承認度也在不斷增長，API的可用性正是讓那些在行業中處於支配地位的公司，甚至是那些僅僅打算用API創建創新性服務的創業公司可以得到成功的關鍵因素。

　　移動設備的出現及IT的消費化趨勢，是對於傳統的企業級應用開發的一次全面轉變。在過去，廣泛存在着各類功能單一的終端主機、客戶-服務器系統、以及最近出現的web的分佈式佈局。我過去也曾談及這種我稱之爲「層的脫落」的現象，即將業務從n層的web模型轉向以API爲中心、以移動和云爲優先的設計。這種轉變也包括了代碼開發從Java企業版轉到JavaScript及其衍生語言的狀況。全部以上這些都代表，正有一波新的開發者，他們將逐漸成爲開發新企業級解決方案的主力。這些開發者們習慣於主動尋找有什麼API能夠知足他們所需的功能。當前的公司應當預計到這種轉變的發生，並迎合新一代開發者的需求，方式就是擁抱API的可用性。

　　讓咱們看一下電信業的狀況。多年以來，各大電信巨鱷們都在處心積慮地想要打倒競爭者，同時也在積極地推出各類跨網絡的增值服務。這個行業在過去的15年間產生了巨大的革新，包括VOIP的出現、業務及運維服務的整合，以及移動設備服務的革命。在種種革新的進程中，API都扮演了重要的角色。即便在傳統電信服務方面仍佔據領先地位，但這些電信巨鱷們也難以從這波革新浪潮中受益。而當他們試圖與Parlay X及OneAPI等創業公司進行合做時，他們遇到的困難比這些小公司更多，Alan Quayle在他的一篇文章中就總結了這一現象。若是這些大佬們都難以抓住此次機遇，又有誰能作獲得呢？

　　建立於2007年的Twilio，其發展目標就是爲客戶提供易於使用的語音及文字消息服務，而且徹底在雲端進行託管。他們一開始就計劃打造這樣一個平臺，而且意識到API會成爲他們第一位的業務方向。SMS和VOIP服務當然頗有用，但爲了與電信巨鱷們展開競爭，他們所需的不只僅是一些便利的電話服務而已。

　　Twilio最關鍵的洞察力在於：他們已認識到所提供的服務的第一批客戶並不是那些調用API的應用的終端用戶，而是那些負責開發這些應用的開發者本人。他們也知道，移動端應用的增加速度必然是最高的。所以，他們定製了一套指標，用以衡量這批客戶對API的滿意程度。除了傳統的終端用戶統計數據，例如端到端的API調用響應時間以外，他們還額外對新開發者註冊這套API所需的時間進行衡量，而且設定了很高的目標。這套指標的設定改善了API的可用性，從而爲Twilio創建了對於各大電信巨鱷的領先優點。當應用開發者們在爲應用的開發選擇SMS或VOIP提供者時，Twilio的這套響應迅速的輕量級服務就明顯比起競爭們勝出一籌。有了這套實用的API以後，Twilio就能夠義正詞嚴地對服務收取費用，經過客戶的每次API調用的付費實現盈利。也正是由於這套實用的API，Twilio提升了公司的名氣，同時也增加了公司的利潤。

　　電信以外的各個行業也對數據革新的方向準備就緒了。就拿 Ingenie來講，這家保險業的創業公司在基於精算的訂價方法方面推陳出新，對於16-25歲這一階段的年青人會進行適當的懲罰。他們經過在每臺汽車裏安裝的一種專利智能設備對每一個駕駛員的數據進行收集，隨後依據這些數據爲這些駕駛員們提供相應的保險折扣。實用的、可用的API使得Ingenie可以實現數據帶來的革新，讓他們像Twilio同樣征服了整個保險行業。

　　實用的、可用的API指南

　　在此進行一下總結，要確保API的成功，能夠經過如下幾個步驟來實現：

• 確保你的API與公司的策略相一致
• 在API中包含可訪問的、準確的而且適用的數據
• 確保你的API是實用的，而且可用的
• 學習Amazon的方式，創建一種規範的文化，迭代式地實現數據帶來的革新
• 學習Twilio的方式，建立一種優秀API開發者體驗，從而使你的業務更勝於其它各大競爭者。

　　只要按照這套指南的方法，你的API終將爲你的業務帶來巨大成功，併成爲這方面的典範。只有你可以最好地判斷怎樣爲客戶提供實用的API。此外，也請各位拜讀一下本系列中的其它各篇文章，它們會爲你實現實用的API提供許多寶貴的建議。