軟體架構設計：API 設計準則（一）、API 的設計開發與挑戰
軟體架構設計：API 設計準則（一）、API 的設計開發與挑戰 前言 最近因緣際會地接下了一門課，這門課是要講授關於 API 開發與設計原則和最佳實踐等相關的內容，雖然我不是第一次接觸這個主題，也曾開發過 2 個 Web API Framework 框架 (以下的 API 均代表 Web API)，只不過，這企業內部 API 開發框架，我們大部分以專案開發的角度來看 API 與 傳統 SPA 前後台網站設計與開發的角度在看每一件事情：像是（分析=>設計=>開發=>測試=>佈署..等）這是大部分開發者熟的純軟體工程，但是切換到 API 的思維會有些不同，這倒也不是說原有的軟體工程不管用，API 依舊是軟體開發出來的，但是整個軟體生態的改變會間接 或者 直接影響軟體服務之間『操作』或『取得』其他服務的方式，尤其在 Cloud 應用與移動裝置的應用會更加的劇烈，一個裝置使用一個公開的第三方服務已經是一個很常見的應用場景 （比如：比如物流商與超商之間 API 的對接、線上售票系統與 iBon 之間的對接、或者代收服務等，這些都是 API 跨領域對接最典型的服務） ，而這邊會談到的是更多直接是以 API 交付出來的雲端服務 Cloud Services、甚至是企業端的平台服務等。 傳統的軟體開發切換到 API 的設計與開發會有那些挑戰？這些我們等一下談。 從軟體工程切換至 API 開發的挑戰 我們常見的軟體工程，不外乎圍繞著專案開發 或 產品開發，這些軟體的終端使用者大都是『人』會會有人機介面，所以不管你是推行 Agile 的軟體開發或是 Kanban 或是 Scrum，我們的最終目標可能都還是完成哪個業務單位『人』想要的『（東西 / 產品）』或者是『市場』（可能）需要的產品。 切換到 APIs 變成 API 與 APIs 協作溝通形成一個最佳的實踐、或 Solutions，你的系統也許是第三方的 API 服務提供者；也許是你也是 GCP/Azure/AWS 等 Cloud 供應商的用戶端，你的軟體系統也是由多個 APIs 所組合而成的 "大系統"，這些 APIs 之間有幾個首要的幾個挑戰要先解決。 (1). 對通訊協定的選擇 也就是像是 HTTP/gRPC/MQTT.. 等等，通訊協定是 APIs 彼此之間溝通的