API

  • 好的 API 要為第三方開發者著想

    Netflix 程式設計總監:好的 API 要為第三方開發者著想

    Posted on

    《TO》導讀:原文來自《The Next Web》,本篇作者Daniel Jacobson 是目前美國網路影音公司 Netflix API 製作團隊的程式設計總監,先前開發過 NPR 應用程式介面,寫過《APIs: A Strategy Guide》一書。

    • 什麼是應用程式介面(API)?

    API 是一種交給第三方程式設計師來使用的「網路工具」,一般公司會釋出其 API 讓程式設計師能夠更有效的利用該公司資源來設計程式或網頁。

    例如 Youtube:

    假如我今天要設計一個網站,上面需要嵌入 Youtube 影片、回應、相關影片等等,那我不必特別寫一大串 PHP 程式碼來讀取 Youtube 影片內容,而是利用 Youtube 官方釋出的 API,將特定的程式碼貼到網頁上,所有內容就會出現了。

    假如沒有 API,就好像要去拆解魔術師的技巧一樣,只能土法煉鋼的慢慢摸索,用一行一行程式碼去測試,才可能把 Youtube 影片的完整內容嵌入其他程式或網頁。因此,API 對一般使用者來說可能不那麼常見,但對程式設計師來說,一個有用的 API 可以省下好幾天的工作時間。

    話說好的 API 讓工程師上天堂,壞的 API 讓工程師整天忙。

    廣告

    所以現今要設計出好的 API 是一件很重要的事情,不只要考慮資源分配、程式負載量,還有版本、安全問題等等。不過在開始設計 API 之前,有一件更重要的事情要決定:API 的目標使用者是誰?要如何對這些使用者量身打造好用且有效的 API?

    聽起來這兩個問題很基本,但如果不先決定,作出來的 API 可能會乏人問津。

    • 很久很久之前,所有程式設計師都用同一種 API 設計

    多年前,網站設計出來的 API 是直接給大眾使用的,並沒有分族群,英文叫做 LSUD (Large set of Unknown Developers),意思是設計 API 的人並沒有針對特定的程式設計師族群量身打造,而是直接把 API 做好,看起來可以讓程式設計師使用起來方便一點就 OK 了。

    這種 API 通常以資源為中心,把架構弄得簡單明瞭,讓程式設計師可以清楚了解這個資源能夠做什麼。

    這種 API 等於以不變應萬變,可以把同一種 API 套用到所有程式設計的應用當中。

    程式設計師就使用這種 API 再去套用到其他的程式碼當中,混合成想要的模樣。不過隨著時代改變,這種 API 會出現一個問題,就是出現太多不同花樣的程式設計工具,包括手機應用程式設計、穿戴裝置、機器人等等。這些不同程式的設計邏輯和語言都不盡相同,如果還是使用同一套 API 邏輯,可能會為工程師帶來非常多困擾。

    • 隨著設計工具種類增加,API 設計開始分門別類

    對於這種變化,出現了另一種針對小眾市場的 API 設計模式,叫做 SSKD (Small set of Known Developers),也就是設計 API 的人清楚知道是哪些程式設計師要來使用這個 API,所以會為這些人量身打造適合他們使用、方便、有效率的 API。

    例如今天我要在網站裡放上 Amazon 網站的「購買」按鈕,這種程式設計邏輯會跟我要在手機 App 裡放上「購買」按鈕的程式設計邏輯會完全不同。

    假如今天 Amazon 想要推出手機 App,把購物功能整合到 App 內,找了另一個團隊來協助設計;這時候原本設計 Amazon 網站的團隊,就必須跟設計手機 App 的團隊溝通,專門打造一個 Amazon 網站的 API 交給該團隊使用。正因為設計 API 的團隊已經知道這個 API 是要交給設計手機 App 的團隊來使用的,所以設計出來的 API 會完全符合設計手機 App 的邏輯。

    隨著裝置種類增加,API 的設計就無法再一意孤行,以資源為考量的 API 在今天的世界仍然可用,但對程式設計師來說時間越來越緊湊,一個有效實用的 API 才是最佳的 API。

    對推出 API 的公司來說,必須要有更方便、更有效的 API,網站的資源才能讓更多程式設計師採用,也能讓更多使用者及消費者利用。在這一片網路紅海當中,誰的曝光度越高,誰就是最大贏家。

    • 新一代的 API:整合性 API

    整合性 API,指的是 API 本身會根據目標使用者的不同,自動將特色和元素突顯出來,以供特定的程式設計師使用。目前有非常多整合性 API 設計模式,但大部分仍保有同樣特色。

    在設計整合性 API 之前,幾個原則要先知道:

    1. 大多傳統 API 設計的目標都是要保持資料結構完整,但整合性 API 勢必會考因慮到更良好的運作方式,以及針對不同設計師的邏輯,而把原本的資料結構打散。

    2. 許多 API 是由第三方程式設計師自行研發,為的是要提供更方便的程式支援。在設計整合性 API 時,則勢必會為第三方設計師增加許多困擾,因為整合性 API 已經有它自己的邏輯,第三方設計師要自行改造的話會更加複雜。

    聽起來是否傳統的 API 就能滿足第三方程式設計師了?別搞混!整合性 API 原本就是為了第三方程式設計師能夠更有效運用網站資源而設計,儘管會變得更難改動,但相較之下仍然能夠帶給設計團隊較有效的方式。

    3. 先了解設計出來的 API 有多少人要使用,這會影響到是不是只需要設計一種整合性 API,還是說如果人數非常龐大,則還是可能額外需要傳統的「以不變應萬變」API。

    • 以下列出幾種常見的整合性 API:

    以裝置整合為主的 API

    這是最常見的方式,假如企業已經有在使用的 API、有支援的 API、正在研究的 API,那很有可能因為上面提到的三點而需要整合性的 API;因此,該企業會持續提供現有的 API,但再加上一個整合功能 (Wrapper),也就是會自動整合所有 API 現有的功能、定義值等,方便不同族群的程式設計師選擇切入點 (Endpoint)。

    例如 iPhone App 設計師,在這種整合方式當中會和 API 團隊密切溝通,以取得更為客制化的整合功能,方便使用者在 App 內操做到某一功能時,App 可以利用整合功能快速取得已經定義好的功能(Function),省下更多程式資源。在這種情況下,通常是 API 團隊來設計切入點和整合功能。

    以回應需求為主的 API

    如果針對裝置整合而設計的 API,可能會對 API 團隊產生額外的負擔,所以出現了另一種 API 設計模式,就是提供一種功能,根據第三方開發團隊的需求,在資料庫中攫取需要的資料。

    這種方式,是將以資源為主 API 加以打散、變化,變成一個資料庫,讓第三方開發團隊可以彈性調整程式負載、需要的功能,也可以進行延伸。這種 API 設計方法的優點,就是 API 設計團隊設計好一個回應需求的功能,就不用再為不同裝置煩惱了。有需要的,自己去 API 裡頭找吧。

    不過這種方式仍然無法跳脫傳統框架,因為第三方開發團隊仍然要學著如何使用 API,並不是像上面說的由 API 整合性來適應開發團隊。

    以使用經驗為主的 API

    以使用經驗為主的 API,簡單來說是上述兩種 API 的綜合版本,也是目前 Netflix 採用的 API 版本。在這種 API 模式當中,有提供針對不同裝置提供的整合功能,但這些整合功能是針對第三方開發團隊所量身訂做的。

    最重要的概念,是 API 設計團隊收集不同的使用資料,但這些資料的擁有者是第三方開發團隊;這樣的關係讓第三方開發團隊在開發程式或網站時,可以根據目前的需求來重新調整資料內容,不再是以被動方式適應他人設計的 API。

    當然,整合性 API 不只有這三種模式,但目前最常見、實用的模式就算這三種。最重要的,是過去 API 設計人員把第三方開發團隊當作使用者,把 API 設計好以後交給他們使用;現在應該讓他們擁有掌控權,自己設計自己需要的 API。

    另外,這種概念也將 API 設計團隊與程式開發團隊融合,共同設計出讓終端使用者體驗的程式或網站,從此之後,API 設計團隊再也不需要一直擔心要如何推出更好的支援服務,而是站在第三方開發團隊的角

    (資料來源:The Next Web、圖片來源:SLU Madrid Campus, CC Licensed)

  • 沒有 API 的軟體產品 = 不能上網的電腦 = 沒有人要!

    本文原作者為 Brian Koles,他在線上軟體競賽資訊平台及工程師社群 ChallengePost 擔任業務主管 。

    如果有一台擁有超棒處理器與顯示器的電腦,卻無法連線上網,很多人可能會覺得這是台沒什麼用的電腦;而在不久的將來,沒有應用程式介面(Application Programming Interface,API)的公司,也會像一台不能上網的電腦一樣,沒有人會想要。

    雖然聽起來有點像危言聳聽,但 API 真的很重要。就像人類無法獨自生存一樣,科技也必須透過互動與合作來達到最大的效益,而 API 正是替你的科技介紹新朋友的媒人。

    • 何謂 API?

    根據 維基百科,API 是一組數量上千、極其複雜的函式和副程式,也是軟體系統不同組成部分銜接的約定。換句話說,程式設計師可以依據 API 來架構出各種應用程式,因此一些系統廠商也常為了讓第三方的開發者可以另外開發應用程式來強化自家的產品,而開放 API,讓這些 APP 能夠與主要的系統溝通。

    如果說,軟體開發人員是未來的搖滾巨星,那麼 API 就是他們演奏歌曲的樂器。API 除了能讓老闆尋得新客戶、讓付費更便捷,還能隨時僱用到支援人員。此外,無論是海外股票交易、規劃大型軟體開發計畫,或是創造最新的生活家電,也都和 API 息息相關。

    在〈關於開放 API,Google 等網路巨頭教我們的五堂課〉一文中提到, Google Map 的 API 讓第三方的開發者可以輕易的使用 Google Map,與 Goole 龐大的地圖資料銜接,並鑲嵌在自己的網路;Salesforce 在網路上提供了一套 CRM(Customer Relationship Management,客戶關係管理) 介面,幫助使用者做客戶管理,並開啟 SaaS(Software-as-a-service 軟體即服務)的先鋒;Twitter 利用 API 分享他們龐大會員的資訊;Amazon 則提供了一個主機代管的應用介面,來幫助新創公司。

    • 如何加入 API 的世界?

    剛開始從一間封閉的公司邁入 API 的世界時,可能會碰到許多的問題,但這些都是必要的,也會是值得的。以下是幾點建議,希望對於有意投身 API 的公司有所助益:

    廣告

    1. 首先要確定終端用戶是誰

    該 API 將會被公司內部的開發人員使用,還是外部的,還是兩者都有?許多大公司的 API 都是設計來給公司內部整合系統用的,但之後很可能會有合作夥伴想藉由 API 來達到雙方互惠,於是該 API 便可能需要重新調整,以合乎第三方的系統。

    2. 建立管理平台

    目前市面上已有許多 API 管理服務可以處理用戶初次體驗(onboarding)、課稅及使用者回報等各種問題。利用這些已經成熟的管理服務,就可以省下自行從頭建立一個平台所需的成本。此外,這些服務通常都會提供各種白牌入口網站(如 developer.COMPANYNAME.com)來建立公開的開發者帳號。

    3. 確立溝通管道

    就算 API 僅供內部使用,也必須建立一個討論平台來回答開發者們的疑問,並不時更新公告及使用說明來回答常見問題。若是公開的 API,則最好建立一個專屬的部落格或是社群媒體帳號,用來公告重大更新或是合作夥伴的成就。

    4. 舉辦活動

    就算做出了 API,也不見得有人會想要使用它,因此為了吸引開發人員,就要多參加會議、舉辦工作坊,或是贊助駭客松(hackathon)及線上比賽。就算是公司內部使用的 API,也可以藉由舉辦公司內部的駭客松比賽來增進員工的熟悉度,進而提升公司的整體效益。

    5. 成立網路商城或是商品陳列架

    呈現那些藉由 API 所製作出來的應用程式,除了能夠提升下載數量,也會鼓勵其他的開發人員一同來設計新的應用程式。就算是公司內部專用的 API,也同樣可以製作一個屬於公司內部的陳列架。

    (資料來源:ReadWrite;圖片來源:jared, CC Licensed)

  • 關於開放 API,Google 等網路巨頭教我們的五堂課

    關於開放 API,Google 等網路巨頭教我們的五堂課

    Posted on

    在開課之前,讓我們先了解「API」是什麼東西吧。

    API 為 Application Programming Interface(應用程式介面)的縮寫,通常是一些系統廠商,為了能夠讓第三方的開發者可以額外開發應用程式來強化他們的產品,所推出可以與他們系統溝通的介面。

    例如 Google Map,第三方的開發者可以輕易的使用 Google Map 所提供的套件,與 Goole 龐大的地圖資料銜接,並鑲嵌在自己的網路;Salesforce 在網路上提供了一套 CRM(Customer Relationship Management,客戶關係管理) 介面,幫助使用者做客戶管理,並開啟 SaaS(Software-as-a-service 軟體即服務)的先鋒;Twitter 利用 API 分享他們龐大會員的資訊;Amazon 則提供了一個主機代管的應用介面,來幫助新創公司。

    那我們從哪裡開始設計 API?我的 API 該提供什麼服務?他可以得到收入嗎?有什麼動機可以讓第三方的開發者來使用我的 API?

    讓我們以網路巨人為鏡,來學習他們的操作方式吧,開課囉!

    • 第一課:把你的 API 當作一個賺錢的事業

    API 可以是你原本服務的延伸,可以是和其他 API 互動的橋樑,甚至可以直接產生收入。

    在 2000 年,Salesforce 催生了一個 SaaS(軟體即服務)的商業模式,透過提供使用者帳號,讓客戶自己將資料填入 CRM(消費者關係管理)系統,並設計更彈性的使用介面讓客戶可以自訂表單的內容。

    廣告
    • 第二課:用 API 為客戶降低成本,創造效益

    Amazon 起初只是一個書籍零售商,後來跨到了出版業。不過大家都知道,他們還有一項為人所知的雲端伺服器服務「AWS」(Amazon Web Services)。

    Amazon 認為,一般的新創公司在草創初期,會在基礎設備上遇到很大的困難,伺服器和架站等等的成本,讓新創公司寸步難行。所以他們提供了包含伺服器代管、資料儲存等服務,建置公司所需要的完整套件,讓小公司可以用較低的成本達到大企業的服務水平。

    像 Instagram 和 Pinterest 在建置初期,都使用過這套系統,現在他們已經變成了家喻戶曉的知名企業了。

    • 第三課:與第三方的開發者一同開發

    Twitter 裡頭有大量的會員,也累積了許多的推文(每則 140 字以下)。這些會員和推文變成了一個龐大的資料。而 Twitter 也清楚本身這個優勢,所以提供了 API 服務,讓資訊可以更輕易的分享出來。而越多的資訊分享,也造就了越多的 Twitter 使用者。

    Twitter 為了使他們的 API 更強大,提供了一個完整的開發者入口網站,放置了一些實用的教程。並使用 OAuth 協定(Open Authorization,授權第三方的網路使用者,在不用得知資源擁有者的帳密時,可以與其索取儲存的私密資源),讓開發者可以共同編寫程式。隨者有更多的開發者加入,Twitter 的服務也變得更健全、更好用,當然受惠最多的就是廣大的 Twitter 使用者。

    • 第四課:專注在可用性

    Google 提供了許多資料和服務,包含了 Google Map、Gmail、Youtube 等,Google 使用了一些簡單和可用性高的 API 來串連這些資訊,並提供了直覺的介面,讓使用者輕易的鑲入適合的功能,和自己開發的服務做整合。

    為何 Google 所開發出來的 API 都這麼好用呢?

    在於「實驗文化」,他們很樂意在市場上做一些小賭注,做出一些天馬行空的 beta 版嘗試,來收集使用者的回饋,讓產品更成熟,確保產品在最後推出時的可用性是很高的。

    • 第五課:將一到四課融會貫通,集其大成

    每家公司都希望可以利用 API 增強他們的服務,所以每家公司都應該站以下在這些網路巨人的肩膀上,看一下如何應用 API。

    Salesforce:讓你的 API 變成一個賺錢的管道

    Amazon:用 API 為客戶降低成本,創造效益

    Twitter:創造一個讓開發者感到很有挑戰的環境

    Google:讓 API 變得好用再更好用

    將一到四課的方法融會貫通,相信可以幫助你的公司在這個社群網路的時代,有更大的成功機會。

    (資料來源:VentureBeat;圖片來源:Kalexanderson, CC Licensed)

  • 開發應用,API先行

    開發應用,API先行

    API的設計與開發,以往我們總認為其原始目的是為了供第三方使用,但其實不然,也有越來越多機會,是為了自身在開發產品或服務所需

    在多年以前,API(Application Programming Interface)像是一個很特定、很專門的軟體領域,只有很少數的人才會需要設計、開發 API,例如作業系統的開發者。我們絕大多數的人,都是 API 的使用者,就像 Windows 的應用程式開發者,幾乎都會成為 Windows 作業系統 API 的使用者一樣。

    不過,隨著軟體重複使用程式碼的觀念愈來愈興盛、層次畫分愈來愈細,在作業系統的 API 之上,有愈來愈多應用層級的 API設計出來。針對不同的應用領域,從低階到高階,讓位處在最高層的應用程式,愈來愈容易在底層的 API 的支持之下,輕鬆開發出應用程式。

    API開發的目的是什麼?實際使用上,有那些方式?

    最早我們對 API 的概念很簡單,API 大抵上是專門以服務第三方的開發團隊做為目的。就像很多年前,微軟內部有個開發共用程式碼的團隊,他們開發出來的產物,同時要供Microsoft Word 及 Microsoft Excel 使用一樣。這個團隊專門就是在開發 API,提供其他團隊,像是 Word 或 Excel 團隊來使用。

    事實上,現在我們所運用的許多 API,也都是專門為了第三方的開發團隊而設計、提供的。

    像是我們會用 Facebook 提供的 Graph API ,來存取 Facebook 為了其應用程式開發者而提供的各種服務,或是利用 Google開放的 YouTube API ,來存取 YouTube 上的資料。

    不過,另一方面,即使是開發同一個產品或服務的團隊,也可能在開發產品或服務的過程中,設計並開發出一些 API,其原始的目的與考量,不見得是為了供第三方使用,而是為了自身在開發產品或服務使用。

    這的確是個有趣的轉變,從什麼時候人們開始這麼做?這麼做能帶來什麼好處呢?

    開發應用的同時,不單是實作相關功能,也涵蓋到API

    最近我們有一個線上影音串流的服務推出,允許使用者從一些不同的終端上收看線上影音,包括了手機、平板電腦、機上盒,以及電視,作業系統包括 Android以及 iOS。當然,在不同平臺上的應用程式都是不同的實作。

    可是,即使是不同的實作,它們還是共用置放在雲端上的服務。也因此,我們為雲端上的這組服務設計了對應的 API,並且在 Android 及 iOS 平臺上,都實作了這組API 的對應實作,這使得 Android 及 iOS 上的應用程式,都可以同樣的概念及模式,來存取雲端上的服務。

    事實上,這並不是我們第一次這麼做了,從很多年前,當我們設計、開發相關的服務時,除了應用程式本身的開發之外,也同時將服務端的部份,以 API 的形式來設計及實作。

    所以,我們可以說,是在開發應用程式的過程中,同時也開發出這個應用程式所需的 API,而在之後,在其他平臺的應用程式,也因此順理成章,共用了相同的 API 介面。

    採用API形式來設計各種應用服務的好處多

    即使,我們一開始沒有打算將這組服務提供給第三方使用,而只打算供給內部,但仍然以 API 的形式及規格,來設計這服務對應的 API。

    而且,其實,你也可以看到,有很多的團隊也都這麼做。這已經形成一種開發應用程式的方法,也就是在開發時,將應用程式本身再拆解成兩個部份。

    一個是核心的部份,一個是外圍的部份,二者獨立設計、獨立開發,但外圍的部份,相依於核心的介面。

    核心的部份,可以說是外圍部份的API,它是具備一般化、通用的部份,而外圍的部份,則基於核心部份的API ,實作應用程式中特化的部份。

    將應用程式如此畫分,可以得到一個顯而易見的優點,是日後一旦要「換殼」,也就是要更換外圍部份的時候,核心的部份完全不受影響,也毋需改變,只需要開發出新的「殼」即可。

    例如,原先只是開發在 Android 平臺上的應用程式,但即使之後增加了開發 iOS 平臺應用程式的需求,也只需要增加 iOS 部份的實作而已。

    也就是說,在這種方式底下,我們在一開始就把可能會被重複運用的部份先抽離出來,並且將它們以 API 的形式來呈現,這使得日後我們要開發新的應用程式時,直接可以沿用這組 API。

    所以,程式碼的重複使用,將會是這種方式顯而易見的好處。

    當 MVC(Model View Controller)的設計模式,或是SOA(Service Oriented Architecture)之類的設計方法,開始廣泛使用之後,許多人將對 Model 或是服務的存取,包裝成為 API 的形式。

    另一方面,由於同一個應用經常被要求提供跨平臺的實作,例如,行動應用程式時常被要求要同時提供 Android 及 iOS 兩種平臺的應用程式實作,但其實骨子裡是相同的服務。現在流行的方式,是將真正的核心程式置於雲端之上,並且,將核心的部份以 RESTful  API的形式提供服務。

    而 Android 或 iOS 的應用程式,基本上的責任,也只有接收來自使用者或裝置的輸入(像是觸控、手勢、GPS 位置、麥克風、相機、……等等),以及顯示使用者介面,並與使用者互動。

    絕大多數的核心程式,都包裝成為運行在雲端上的服務,而且可以被諸多不同平臺上的實作所共用。

    思考應用當中不變、共通的部分,提升當中的再用性

    這種在開發自身應用程式時,即將應用程式畫分為 API 及應用實作兩部份的設計方法,還有一個好處,也就是它有助於設計者更認真思考:自己正要開發的應用中,究竟那些部份是可以維持較長時間不變,而保有其一般性,以及那些部份是容易隨著實作而變動的部份。

    當你在設計一組 API 時,你不僅會考慮到在自己正在開發的這個應用中的需求,同時也會考慮到,倘若有第三方的開發者,也想要開發一個和這個應用核心精神相同,但展現實作不同的應用程式時,這組 API 是否足以滿足他們的需求?

    當你用 API 的規格來看待、想像,可能有一天你會釋出這組 API 供第三方開發者使用時,基於這樣的思考方式,將能幫助你寫出通用性更高的程式碼,進而帶來了更高的可重複使用能力。

    那些和平臺相依、隨著實作會有所變動的,都會被你從核心的部份抽離,而核心的部份,只會保留較純粹的特質。

    當你在開發應用程式時,試著將應用畫分成為 API 以及應用實作兩個部份時,能夠幫助你更明確的思考那些是核心,因為你在依循 API 的設計觀念時,會將它們包裝成為 API。

    但是,有些人不會隨時保持著這樣的思考方式,使得他們時常將二者混雜在一塊,也就不容易寫出足夠通用、能持續被重複運用的程式碼了。

    即使我們不打算開放內部使用的 API 供第三方使用,但是,在開發應用時,如果能夠總是先想到有那些可以成為 API,並且用 API 的規格去設計實作,對自身的應用之開發,如此一來,還是可以帶來不少好處的。

  • 為何你該考慮 API 優先的開發模式和商業策略?

     by 王昱程

    為何你該考慮 API 優先的開發模式和商業策略?

    隨著行動裝置的爆炸性成長,穿戴式裝置的湧現,以及 IoT(Internet of Things)產業的發展,過去傳統的 Web 瀏覽已經不再是使用者接觸資訊的首要選擇,如今企業需要面對的是一個多渠道的商業模式。資料和資訊的傳遞,不再只侷限於網頁瀏覽器或手機行動裝置之間,未來將延伸到任何具備網路能力的設備,像是手錶,汽車,或是家電。因此企業提供 API 讓合作夥伴能夠存取,甚至免費提供開發者開發延伸應用,將會是未來企業獲利的重要方式,甚至是不可忽視的商業策略。

    根據 Programmable Web 的統計,截至目前為止(2015/1/9)有 12,684 個可供查詢和使用的開放 API,且仍持續不斷地成長中,若加上未開放的企業內部或未公開的 API,其數量可能是以十倍甚至是百倍來計算了。以下列出5項原因,說明為何企業或新創公司在設計產品或提供服務時應該考慮 API 優先(API-First) 的開發模式或是開放 API 商業策略。

    1.未來將是全通路(Omni-Channel) 的時代

    從過去 Web 瀏覽的單一管道,到行動裝置的多管道,未來將會有更多的商業渠道產生,例如穿戴式裝置,Connected Car 等,甚至是許多尚在開發中的未知裝置。將來任何能夠連上網的設備,都會是企業拓展商業的機會。

    2.平台化(Platformization)

    許多的 App 或服務,透過開放的 API 讓開發者或第三方服務得以開發出新的應用,也因此, App 將不再是單純的一個 App, 透過開放 API 它可以變成一個平台,讓其他合作夥伴得以擴充既有的功能或是創造全然不同的使用體驗。例如 Evernote 透過開放 API, 讓許多公司開發出更多優秀的App, 無形中也透過這些 App 加強了使用者對 Evernote 的黏著度。而去年被 Facebook 收購的 Moves App 也透過開放 API, 讓開發者創造出更多新奇的應用。

    3.將商業邏輯和使用者介面分離

    對開發團隊來說,API 優先的開發模式,將有助於團隊專注於內部商業邏輯,同時讓網頁前端或是手機 APP 的開發得以同步進行,大幅提升整體的開發效率。除此之外開發團隊只需要維護核心的 API 程式,有助於降低整體維護的複雜度。

    4.不要重複開發新輪子

    越來越多公司將自身的服務透過網路 API 開放出來,除了過去大家耳熟能詳的 Amazon、Google、Microsoft、Heroku 等公司,有更多的公司以 XaaS(Everything as a Service)的形態出現,例如提供資料庫服務的 Orchestrate ,提供郵件服務的 Mailchimp , 提供 logging 服務的 Papertrail 等公司,新創公司在初期得以專注在自身的商業邏輯,透過這些服務或工具快速建構產品雛形,調整設計架構,進而縮短整體開發和產品上線的時程。

    5.API 經濟體 (API Economy) 已然成型

    由於越來越多具網路能力裝置和設備的產生,以及因為開放 API 所帶來的新形態應用, 企業,政府,甚至是個人,透過使用或提供 API 讓彼此的系統或服務得以串聯起來,開創出許多新的商業機會和應用模式,而這一切必須建構在具有健全穩固的 API 基礎架構前提之上。去年提供 API 管理服務的 apigee 得到 6000 萬美金挹注,將協助企業建立更完善的 API 管理機制和分析服務,而提供開發者 API 監控和測試服務的 Runscope 也在 2014 年獲得 600 萬美金的資金投資,未來也將針對企業客戶提供更進階的功能和支援。

    回顧 2014 年,API 的重要性已得到更多的關注,許多的 Conference 和社群活動,如 APIStratAPIDaysAPIConI Love APIsGlueconREST Fest 等,讓 API 相關的產業議題得到更多討論。 3 Scale 甚至在針對2015 年的預測中,將 API 設計能力視為一個相當重要且進階的技術能力。 相信, 2015 年將會是 API 經濟體突飛猛進的一年,有更多的 API 被開放出來,更多具網路連結能力的裝置透過 API 互相連結,以及圍繞在這之中更多的商業模式和契機等著你去發現。