API 設計 - API 整合矩陣

API 存在的目的，最早期是程式邏輯可以重複使用，例如時間相關的工具，透過標準的介面定義，以及模組化的概念，每個人在開發應用程式的時候，都可以引用同一個函示庫，透過標準介面就可以調用。像是 Java 語言的 java.util.Date 這樣的標準介面，所以 API 的概念就出現了。

後來程式跟程式之間也要相互調用，像是 Java 要使用 linux ls 的資料，所以產生了 Inter-Process Communication (IPC)，讓 Process 跟 Process 之間可以相互調用。

但這都還是在同一個作業系統裡面，分散式系統的出現，開始出現 RPC (Remote Procedure Call)，讓跨系統之間可以相互調用，做出更複雜的功能。

類似的概念，到了 Web / HTTP 出現之後，SOA 概念興起，跨服務之間的溝通，就變得更重要了，API 的概念又被更放大了。

什麼是 API？

API (Application Programming Interface) 指的是讓 兩個以上 的 異質系統，相互調用彼此功能的可程式化介面。例如：

在 Windows (作業系統) 上有一個行事曆 (Desktop 應用程式)，他需要取得 Windows 本身提供的時間資訊，所以調用 Windows.Date() 取得現在的時間。

這個例子，Windows 和行事曆兩者就是異質系統，而 Windows 提供的 Windows.Date() 就是個 API 介面，通常這種稱為 Syscall。

API 泛指各種可以相互調用的介面，包含以下：

Libraries: 各種 C 的 .h、Java / C# Code 的 Interface 都算是
- 同一個程式語言之間，使用彼此功能的介面
RPC: Remote Procedure Call 遠程調用介面，技術觀點就是跨語言 / 跨系統之間的調用，垂直整合 (系統與程式)、水平整合 (系統與系統)
- Web: 基於 HTTP 協議的介面，也是本文的主角，屬於水平整合的 系統與系統 溝通
- SSH: 透過 SSH 下的 remote call

常見的 API 整合方式，以 提供者與使用者 的角度，API 形式則用 系統與程式 區分，定義這兩者如下：

Pub/Sub：API 有 提供者 (Publisher) 也有 使用者 (Subscriber)，負責整合兩者稱為 API Platform，是個管理角色。
系統：只作業系統、或者 Web Services
程式：應用程式，像是 Desktop、開一個 Port 走 TCP / UDP 的應用
- 應用程式之間大多透過 Inter-Process Communication (IPC) 交互通訊，更多參閱 Shell and Bash Concepts

依照這樣的定義，整理出以下的整合矩陣：

這四個象限分別說明如下：

A: 指的是系統發布 API ，提供給程式使用
- 例如：Linux 提供 Syscall 給應用程式 ls 使用。
B: 程式跟程式之間相互調用使用，例如：
- 使用 Springboot 開發 Web 應用，Springboot 是一個框架，開發者寫出自己的邏輯，背後調用框架的 API.
- 這裡指的程式是同一種語言，如果是不同語言，那屬於 D 象限。
C: 與 A 相反，程式語言提供介面給系統使用，例如：
- 微軟瀏覽器 Edge 的常駐程式，當需要更新版本的時候，提供介面讓 macOS 調用，並通知使用者有新版本更新
D: 系統對系統，像是：
- Web Service 彼此之間 API 的調用
- Linux 之間的溝通與調用 RPC，也是這個範圍
- 如果是跨作業系統溝通，例如 Linux 調用 Windows，這年代大多會封裝成 Web API 的方式調用，例如 AWS 的 microVM - FireCracker 預設就有 WebAPI 可以使用

因為分散式系統的大爆炸，所以 D 象限大爆炸，特別是基於 Web / HTTP 的 API，所以現在口語上說 API 的時候，很多時候都是泛指 Web API，特別是 RESTful API，當然也會包含其他像是 gRPC / GraphQL 等不同的實踐技術。

實際上 D 範圍包含 A / C / B 三大塊，也就是為了達到 D 的目的，開發工作會橫跨另外三個。