OAS

前言 本篇算是整理下目前自己對 API 的理解，算是雜談性質，就記錄一下吧。 什麼是 API (Application Program Interface) ? 從文義解釋開始 從文義解釋來看，API 的基本定義是：軟體之間溝通的介面，允許不同系統有規範地交換資料。API 規範了如何向服務提出請求、需要的資料格式，以及回傳結果的形式。 然而文義解釋總是過於抽象，我們還是舉例來說明會比較清楚。在介紹何謂 API 時，最常聽到，會用餐廳點餐來比喻，我這裡也不免俗地用這個方式來說明。 餐廳的例子 Image Source Credit: Celeste Layne - Medium.com 你是餐廳的顧客，菜單代表「服務可以提供那些資料、功能」。當你向服務生點餐（發送請求），服務生將你的請求帶給廚房（資源所在，也就是後端系統）。廚房根據菜單和你的選擇（麵要加大不要辣）的選擇製作食物（處理請求）。最後，服務生把餐點（回應）端給你。 在這個比喻中，服務生就像 API，客戶端（顧客）不直接與後端（資料、邏輯、資源）打交道，而是透過 API 這個介面來溝通下單和取得結果，省去彼此理解內部細節的麻煩。 但是，工具的目的是為了解決問題，重要的不是工具本身，而是背後要解決的那個問題。因此我們要進一步思考的是，如果沒有 API，會如何？ 軟體之間就必須「直接訪問」彼此的資料或功能，彼此須了解對方的內部細節，如同點菜時顧客沒有按照制式的菜單點餐，廚房根本不知道怎麼出菜，最後本人必須進廚房了解每一道手續，如此一來餐廳根本無法運作。但若真的讓顧客直接進餐廳，如此，就會缺乏安全隔離，外部程式可以隨意取得資料，使系統變得脆弱，就像顧客可能將病原體帶入廚房，污染食材。同時，維護上若有需要調整，將會修改困難，比方說內部實作細節更改，取用者要如何取得資料，必須重新理解取用過程。 舉例來說，如果沒有 API，你開發一個 App，需要取得 google 地圖的資料、處理金流等功能時，你得直接接觸這些系統的底層，理解提供服務者的內部結構才能夠拿到你想要的東西。 訂購人的困境 OK，現在每一家餐廳都有自己的菜單與訂購單，解決了廚房的溝通問題。這解決了單一廚房點餐的問題，基本上只要看得懂上面菜單的文字，就可以知道這張單要出甚麼內容。我們有了 API 了！ 但若場景變成：要對多個餐廳要同時下單，你是訂便當股長，就會遇到要對應不同便當店，要看懂每家的菜單格式，還要想辦法看懂各位同事自由格式的信件內容，也就是你要適應不同格式，結果就是增加了溝通成本。 例如上圖，每間餐廳的菜單風格迥異。 開發人員的困境 回到開發場景。來做個系統吧，資訊人員一定會幫我們解決這個問題，降低便當股長的離職率。但資訊人員遇到了問題，那就是他要去串接的每個店家，他的訂購單格式都不一樣，此時面對了一些抉擇： 鍛鍊資訊人員，所有店家都客製作下去，但這可能會提高資訊人員離職率。 訓練資訊人員的溝通能力，配合專案經理，以及外部合作商，談訂一個共同的規格。 很遺憾的，上面那兩個選項，偉大的老闆選了項目 1，為了不影響其他合作商，所以決定讓自己的工程師處理。 如果每個合作對象（例如不同餐廳）都用自己的格式來傳遞資料，資訊人員（工程師）就必須針對每一種格式，開發不同的「解析」方法。舉例來說： 有的店家用 Word 檔案下訂單，有的用 Excel，有的用 PDF，有的直接寄圖片，有的用網頁表單。工程師就要寫很多不同的程式，來讀取和理解這些不同的檔案格式。 如果店家改變了檔案格式（例如 Word 從 2003 版換成 2007 版），工程師的程式就可能失效，要重新修改。 有的 Excel 檔案可能被植入病毒，還要擔心安全問題。 如果是圖片，還要用影像辨識技術來「看懂」圖片內容，萬一圖片字體換了，辨識又會出錯。 ...