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

 

《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 設計團隊再也不需要一直擔心要如何推出更好的支援服務,而是站在第三方開發團隊的角度,仔細思考他們需要的開發方式。

  • 延伸閱讀:

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

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

Coding 自學網站 Codecademy 聯手 Twitter、Evernote 再推 API 課程

Google Maps API 跳樓大降價!Google 緊急回防 Apple?

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

點關鍵字看更多相關文章: