《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 的軟體產品 = 不能上網的電腦 = 沒有人要！
Coding 自學網站 Codecademy 聯手 Twitter、Evernote 再推 API 課程
Google Maps API 跳樓大降價！Google 緊急回防 Apple？
（資料來源：The Next Web、圖片來源：SLU Madrid Campus, CC Licensed）
Source: techorange.com
