持續 API 管理 - ch1 管理 API 的挑戰與承諾

本書嘗試著解決一個問題,作者試圖找出各種 API 管理成功的案例下所具備的共同特徵,並彙整分享。

在管理 API 時,還有個重要的挑戰,那就是我們必須要區分「設計、建構與發表單一 API」、「支援和管理多個 API(本書稱之為 API 園林 (landscape) )」之間的差異。

最後,書上則會討論 API 生態系統的管理決策程序。

然而在討論以上議題前,我們先來看兩個重要的問題:什麼是 API 管理,以及為何它如此困難?

什麼是 API 管理?

如同前面所說到, API 管理並非只和設計、實作與發表 API 有關。同時也包含 API 生態系統的管理、如何在組織裡發俵決策,甚至是將現有的 API 遷移到正在成長的 API 園林等過程。

但在討論這些之前,我們需要討論 API 存在的終極理由,即 API 商務

API 商務

除了建立 API 與管理他們的細節外,製作 API 本身完全是為了支援商業目標和目的, API 通常是釋放組織現有價值的一種方式。

以下有幾種商業目的的方向及釋放組織價值的方式可參考

存取資料

API 為企業做出貢獻的一種方式是讓人們更容易取得重要的客戶或者是市場數據,這些數據可能可以創造出新的商業價值。(例如 GA)

接觸產品

API 可以作為「工具」來建構一套新的解決方案,降低某些成本。(例如 AWS)

獲得創新機會

在公司內部建立以 API 為核心的基礎建設,可以提高各方面的效率。(例如 人資系統)

什麼是 API

人們有時用 API 來代表介面、有時代表功能,當然這兩種意思廣義上都沒錯,只是有時候他們會造成混淆。

為了釐清這種區別,以方便我們討論介面與功能,底下將介紹一些額外的術語:「介面」、「實作」、「實例」。

介面、實作與實例

API 是 Application Programing Interface 的縮寫。我們會用介面來使用在 API 背後運行的東西,這個介面通常是以某種共享的協定來表達(如: HTTP, TCP/IP … 等),並採用某種標準格式(如:JSON, XML … 等),但這只是介面,而我們還需要其他東西去執行這個介面所要完成的工作,這個部分就是實作

實例則是 API 介面與實作的結合,適合用來代表已被投入生產環境並開始運行的 API。

API 風格

API 另一個相當重要的元素就是風格(style),例如當今最常見的 REST 或 RESTful API 風格。但風格只是一種選擇,而現在也越來越多人使用非 REST 、非 HTTP API ,事件驅動架構(EDA)的興起就是很好的範例。

幾乎沒有一個公司在整個內部只依靠一種風格,而且,無論何種風格都不太可能永遠不變,但是在設計、實作與管理 API 的時候考慮風格,是建立成功、穩定 API 的關鍵因素。

具有風格的 API 對於管理 API 有另一個重要的層面:以連貫、一致的方式來管理 API 。

不僅僅是 API

API 本身只是完整故事的一部分而已,在 API 的生命週期中,還有其他也相當重要的元素

  • 設計
  • 建構
  • 部署
  • 測試
  • 監控
  • 紀錄
  • 保護
  • 維護
  • 文件

這些書中稱為 「API 支柱」 ,都是在營運、管理 API 中相當重要的議題。

API 成熟階段

除了 API 支柱外,專案中的每一支 API 都會經歷自己的生命週期。

例如:在 API 的早期階段,應該把重心放在建構與設計上,而在往後的其他階段,比較重要的事情是監測 API 的使用。

知道目前 API 處於生命週期的哪個階段可以協助你決定此時要如何分配有限的資源與時間在 API 裡面。

超過單一 API

當我們的 API 不斷成長,來到了 API 園林的階段,此時我們的挑戰大多都是如何確保某種程度的一致性,同時不至於為了集中管理和審查所有 API 的細節而造成瓶頸和速度的下降。

此時很有可能將公司的 API 產品拆分了多個不同的團隊自主開發,也就是說我們必須擺脫常見的集中指揮和控制模式。

而當組織擴大,我們也會常面臨到一個問題:組織的高層往往無法看到團隊層面的重要活動。

在管理 API 園林時出現的挑戰通常與規模和範圍有關,通常取決於 API 專案的增長,遇到的問題也會跟著變化。

為何 API 管理很難?

作者提到,他在走訪世界各地的公司,討論如何管理 API 生命週期時,遇到了些大家共同常見的問題

  • 範圍
    • 當團隊在管理 API 時,隨著時間階段的不同,應該要聚焦在哪裡?
  • 規模
    • 當專案隨著時間增長,在研發 API 初期有效的做法,通常無法隨著專案擴展
  • 標準
    • 隨著專案的成熟,管理與治理工作必須從「詳細的建議如何實作 API」變成較廣義的「API 園林標準化」。

範圍

這邊書中粗略帶到關於早期、中期、後期的方向,詳細內容會在後面章節仔細討論

  • 早期
    • 如何設計和實作 API 的具體指引
  • 中期
    • API 生命週期和他們之間如何互動的一般性指引
  • 後期
    • API 如何隨著時間的推移而彼此互動,以及 API 如何和相關產業或者公司的其他 API 互動

規模

隨著 API 的規模持續擴大,本書將探討哪些元素值得關注,以及哪些工具可以幫助你掌控不斷成長的 API 平台。

標準

當你開始進行大規模的 API 園林管理時,「標準」化對於引導團隊做一致性的設計、部署及實作有相當大的幫助。

管理 API 園林

管理大規模的 API 需要考慮的事情跟設計單一 API 是不同的,書上在這邊提出了管理大規模 API 給 API 管理層面帶來的三種挑戰。

技術

管理 API 園林技術的重點在於,判斷園林何時已經大到可以添加新的技術種類進去,而不是限制他們。其中有些技術和既有的實作現況有關係,例如你需要跟老舊的系統使用 TCP/IP SOAP 溝通,你沒辦法要求對方為你的 API 開立新的 HTTP CRUD API … 等等之類的。

團隊

當你的 API 規模持續擴大,導入了不同的技術,建構與維護 API 所需的技術種類也會增加,我們不能指望團隊內的所有人都擅長設計、資料庫、後端、前端、測試和部署的領域技術,這時你就會需要許多不同的精通該領域技術的小團隊給予支援。

管理

隨著 API 園林的增長,我們的 API 治理模式也要從「直接提供建議」轉換成「提出一般原則」,在轉換成「收集和分享公司內部有經驗團隊的做法」。

結論

第一章大略的談論了 API 管理的一些重要層面,在介紹完背景之後,接下來會談論關於 API 治理的概念,以及如何決策、如何分配決策權,作為整個 API 管理的重要元素。