什麼是 API？ 會有哪些應用？
隨著手機和連網裝置的普及，現在幾乎每個人的日常都會接觸到一個以上的連網裝置 (手機、電腦、物聯網、車聯網，等等⋯)，更有數以萬計的 App 運行其上，提供各式各樣的服務。這股數位化浪潮，正在翻轉傳統以「商品」為中心的商業模式：網路的普及讓人與人，業務與業務間更直接也更高度的連結；分工越來越精細，一個商品或服務可能是由數個服務供應商串接而成；人工智能的崛起，企業開始思考如何利用資料輔助業務決策，產出更高的價值。
這幾股推力 (高連結、細分工、大數據) 催生了新的商業模式：「平台」。「平台」所提供的不再是單向價值傳遞的「商品」而是「服務」。「服務」是可以持續演化生生不息的：透過收集用戶在使用服務的過程中所產生的資料，我們可以從中提取洞見，進一步優化「服務」，是一個不斷演化/優化的過程。而 API 正是走向「平台」模式的敲門磚。
舉個例子 Google Map，想像一下他僅僅是一個「商品」，那他會是什麼樣貌？「一個數位版的地圖，可以在數位裝置上查詢你所想前往的目的地」，但是我們所感受到的 Google Map 是什麼樣子？「找餐廳，我們會開 Google Map；訂飯店，我們也會開 Google Map；要出國旅行了，我們也會看看 Google Map 有哪些景點好玩」，這就是平台，平台提供的是服務，與其說 Google Map 是一個「數位地圖」，不如說他是一個「探索者」服務來得更貼切。
(圖片來源)
歸結來說，「平台」在以下幾點與「商品」有本質上的區別：1. 市場：平台不僅僅關注終端用戶，更多是在賦能開發者。2. 競爭優勢：平台比的不是實體的資源，而是在其關注領域的生態系站位是否足夠全面，是否更能利用資料做出有利的業務決策。3. 價值主張：平台比的不是資源轉化的效率，而是媒合生態系各方資源，更友善的介面體驗，更好的整合開發者和合作夥伴。
API (Application programming interface) 是企業透過標準協定將服務對外開放的介面 (例如常用的 HTTP protocol)，由於規範普及和各種裝置的支援，HTTP 幾乎也成了 API 的代名詞。Google Map 就是利用 API 讓自己一路演化成一個巨大的平台，他開放 Places API，讓終端用戶可以給特定的地點給予評價，所以我們會透過 Google Map 來找餐廳；他開放了 Maps API，可以定位到某個地點看實際的街景圖，所以我們會先看一下周邊街景來決定要不要入住一間飯店；他開放了 Routes API，所以我們會用它來規劃景點造訪的最佳路徑。
除了終端使用者可以直接在 Google Map 上面使用這些服務，更多的是其他服務也整合了 Google Map 開放的 API 達成更好的使用者體驗 (例如 Uber 利用 Maps API 來媒合司機和乘客，利用 Routes API 來規劃最佳行車路徑，等等⋯)。Google Map 這個服務本身也因為開放 API 收集到更多使用者資料，進一步更優化了服務。
“Businesses need to put their brand and new services where their customers are”
在高度數位化的時代，終端用戶是極難取悅的，藉由引入 API，有價值的服務才有更多機會被整合進更多渠道。用戶體驗更好，你的服務也能更快的演化迭代。
開放銀行 (Open banking) – 還權於民、追求用戶利益最大化
“Data has value and belongs to customer”
Open Banking 是近年來金融圈一個熱門的議題，其核心思想為「還權於民」，這裡的權指的是資料的擁有權和使用權。過去我們使用銀行的服務並認為銀行會替我們保管這些交易資料並不被別人竊取，這樣雖然免除了安全性的疑慮，卻也阻礙了創新，讓 banking (泛指財富管理、借貸、投資等金融相關服務) 仍停留在「商品」的舊商業模式，無法轉型為「平台」。
為了刺激創新並挽救自 2008 金融海嘯以後低迷的銀行業，英國於 2016 年提出了 Open Banking 這樣的想法，主張用戶有權決定是否開放銀行以外的第三方使用其交易資料來為其提供更好的服務 (例如：透過分析你的收支資料來給你更好的理財建議)。
這股風潮也吹到了台灣，2019 在金管會的推動下，Open banking 的相關法規已逐步完善並且採取漸進式的做法分階段實施。也因此，API 正開始在金融產業刮起一股旋風。
API 管控（APIM）與挑戰
理解了 API 的重要性之後，我們來看看，如果今天要將一個既有系統轉變成 API first 的服務形式，會遇到哪些挑戰：
- 更好的跨裝置體驗：以往你的服務可能是一個單純的網站，開放 API 後，各種可能的裝置都可以透過 API 取得資料，並做不同的呈現。因此，怎麼讓既有系統能夠跟得上這些不同裝置對於資料不同的期待，成了很大的挑戰。此外，安全性也是很重要的環節，例如：你希望某些 API 是公開的，而另一些 API 則需要授權才能使用。
- 運維的效率：一旦將服務 API 化以後，一個必然隨之而來的問題就是怎麼包裝這些 API 成為產品，並且針對不同的產品有不同的收費策略 (例如：某些 API 可以免費公開使用，而另一些 API 則需要付費使用或者有限定用量的使用)。此外，API 公開以後，流量不再容易估算，系統如何彈性的擴展，也是一大挑戰。
- 資料的收集與分析：如同先前「平台」商業模式所述，API 不僅讓你的業務有機會與其他產業對接，更重要的是你能從開發者/終端用戶獲得更多的資料，並且，這些資料能夠反饋回去，讓你將服務做得更好。
若要在既有系統當中去克服以上種種挑戰，不僅曠日廢時，同時也增加了系統的複雜度 (進而影響到系統的穩定度)。那麼，要怎麼保持既有系統的穩定性，又能滿足 API first 帶來的架構挑戰呢？
答案就是引入一個介於「開發者/終端用戶」和「既有系統」之間的中間層，我們稱之為 API Management (APIM)。透過 APIM 這個中間層，既有系統可以專注於業務邏輯，提供更一致更模組化的服務，而將這些與 API 使用層面相關的問題 (體驗、運維、分析)，交給 APIM 去處理。Apigee 正是在 APIM 的領頭產品。
Gartner 認證 API 管理平台之領導品牌：Google Cloud Apigee
從 API 的設計、開發、部署、監控、分析到擴展，Apigee 在整個 API 生命週期中，都有對應的功能滿足你對於 APIM 的需求。
API Proxy
如前述，APIM 是介於「開發者/終端用戶」和「既有系統」的中間層，在 Apigee 稱之為 API proxy。API proxy 解耦了 client 和 backend 並且各自引入了相應的代理層 Proxy Endpoint 和 Target Endpoint。有了這些代理層搭配 Apigee 預設提供的眾多 policies，透過簡單的 UI drag and drop，就可以快速建構一個 flow，讓你原本的 API 瞬間變得強大。
例如：透過加入 Verify API Key policy 你的 API 馬上就有了基本的 authentication 機制；透過加入 XML to JSON policy，即使你原本的 API 回應只支援 XML 格式，也能馬上支援 JSON 格式。
除了預設提供的 policies，還可以透過 Extension 擴充 API proxy 的功能 (例如：你想要在 API proxy flow 中去呼叫另一個外部 API，並且將其回應整合進原有的 request 中)。更方便的是，Apigee 已經跟很多 GCP 產品有建立好的 Extension (例如：Data Loss Prevention extension 可以將 request 當中的敏感資訊去識別化；BigQuery extension 可以查詢 BigQuery 並將查詢結果放入 API response 當中)。
開發人員入口網站 (Developer portal)
為了吸引開發者使用你的 API，一個好的門面是很重要的，利用 Apigee 內建提供的開發人員入口網站範本 (當然，你可以客製化風格)，你不需要再花額外的時間刻網頁，確保頁面的資訊和 API 的更新一致。在你發佈 API 產品後，入口網站的 API 文件也會跟著同步更新。更重要的，開發者可以直接在 API 文件頁面的側邊欄，直接跟 API 互動。
Apigee API 產品分類
透過 Apigee 的 API Products，你可以根據不同的應用場景將相關的 APIs 組合成一個個 API 產品，產品也是 Apigee 部署的基本單位，並且你可以綁定不同的計價策略在不同的 API 產品上。有了這層抽象，後端模組化仍能保持以功能為主的切分，但是對外開放則以更開發者友善的方式包裝。
Apigee 監控與分析
Apigee 與 GCP 高度整合，在監控與分析這塊無縫整合 Stackdriver (GCP 的監控產品) 和 BigQuery (GCP 的資料倉儲) 的強大功能。透過分析數據，你可以知道哪些 API 是最常被使用的；哪些 API 的響應時間是比較慢的；哪個國家貢獻最多的 API traffic 等等⋯。透過這些分析，你可以進一步改善你的 API，甚至調整你的業務策略。
結語
如果你熟悉微服務架構，那麼對 API 一定不陌生，正如同分散式運算上有 Kubernetes 這樣的容器管理框架；Apigee 同樣也補足了從既有系統走向「平台」商業模式所會遇到的各種 API 管理挑戰。有了 API，有了 APIM，業務可以延伸更多觸角，有更多整合的機會，但這只是飛輪的開端，接著要思考的是怎麼收集更多有用的資料，怎麼利用這些資料反饋回業務本身。
API -> 資料 -> 規模化 = Apigee + GCP，趕緊搭著 App 經濟浪潮來一波華麗的數位轉型吧！
