API

What？

API 全名是 Application Programming Interface，簡單來說，它是一種讓不同程式或系統之間能夠溝通與互動的機制。你可以把它想像成一座橋樑，透過這座橋樑，兩邊的系統可以交換資料或執行特定功能，而彼此不需要了解對方的內部運作細節。

舉例來說，當你使用手機上的天氣 App 時，該 App 會透過 API 向某個天氣服務系統請求資料（如溫度、降雨率等），然後以使用者友善的介面顯示給你。不論是前端與後端的溝通，或者不同服務之間的整合，都少不了 API 的參與。

Who？

API 的主要使用者包括：

開發者：前端工程師用 API 從後端獲取資料；後端工程師則設計 API 供其他系統或開發者使用。
第三方應用程式：透過 API 整合外部服務，例如支付平台、地圖服務。
企業客戶：利用 API 將各部門內部系統串接在一起，提升工作效率。
最終使用者：雖然他們並不直接接觸到 API，但享受到由其提供功能支持的應用程式。

實務上，你可能會遇到一些情境，例如建立一個電子商務網站時，需要向物流公司查詢配送進度，你就需要透過該公司的 API 來完成這件事。

When？

什麼時間點會用到 API 呢？以下幾個情境非常常見：

串接外部服務：例如整合 Google Maps 提供定位功能。
跨系統溝通：當公司內多個系統需要交換資料時。
手機 App 與伺服器溝通：例如社交媒體 App 獲取最新貼文資訊。
自動化流程：藉由呼叫某些自動化工具或平台上的 API 完成工作。

通常在專案開發早期，就會規劃好需要哪些 API，以便確保前後端或跨平台之間能順暢配合。

Where？

API 通常出現在以下架構中的不同部分：

前端與後端之間：
- 前端請求資料時呼叫後端提供的 RESTful API 或 GraphQL。
Microservices架構中不同子系統之間：
- 各微服務彼此溝通時靠著內部定義好的 APIs。
第三方整合點：
- 比如金流、物流服務商提供的 APIs 被嵌入到你的系統中。
雲端基礎設施中（例如 AWS 或 Azure）
- 管理資源或自動部署時，也多半透過它們所提供的 APIs。

Why？

API 的主要目的是解決「如何讓不同技術堆疊有效協同工作」這個問題。它帶來以下好處：

隔離細節、降低耦合度：系統只需知道如何呼叫特定接口，而不需理解另一邊如何運作。例如，你不知道 Google Maps 的定位演算法，但可以輕鬆呼叫其提供的位置搜尋功能。
重複使用性高：一次建立好的 API，可以被多個應用程式重複使用，比如支付接口通常被多家合作夥伴共享。
擴展性強：當你的業務需求增加，只需完善現有 APIs 或新增接口即可擴展功能，而不需大幅改動既有架構。
標準化數據交換格式（如 JSON 或 XML） 開發者能快速理解並利用相同規範進行開發，不易出現混亂或錯誤。

How？

🛠️ 建立階段

建立一個基本的 RESTful API 通常包括以下步驟：

定義需求：
- 確認有哪些功能需要被暴露給外部，例如「取得商品列表」、「新增訂單」等。
選擇框架/工具：
- 常見選擇包括 Node.js + Express、Django Rest Framework (DRF)、Spring Boot 等。
設計路徑與方法（Endpoint + HTTP Method）：
- 比如 /products 使用 GET 獲取商品列表；/orders 使用 POST 建立新訂單。

實現邏輯與處理方式：

// Node.js 範例
app.get('/products', (req, res) => {
    const products = [{ id: 1, name: "Product A" }, { id: 2, name: "Product B" }];
    res.json(products);
});

測試 & 部署：
- 使用工具如 Postman 測試是否正常回應；將程式碼部署至伺服器上供外界存取。

🔍 查詢階段

當查詢某些資料時，可以遵循以下流程：

發送 HTTP Request 至指定 Endpoint，例如 GET /products?id=123。
後端根據請求解析參數並查詢對應資料庫內容，例如 id=123 的商品資訊。

回傳 JSON 格式結果至前端，例如返回如下內容：

{
    "id": 123,
    "name": "Product C",
    "price": 199
}

前端接收並解析結果，再根據需求渲染 UI 顯示給使用者。

補充說明

📌 範例比較

以下比較兩種常見格式—— JSON 與 XML：

格式	可讀性	資料大小	常見用途
JSON	高，可讀性強	較小	Web 應用程式
XML	中，需要標籤解釋	較大	標準化文件傳輸（如 SOAP）

🧠 延伸／常見誤解

誤解：「所有 APIs 都是 RESTful。」澄清：除了 RESTful 外還有其他形式，如 SOAP 與 GraphQL，各有適用場景。例如 GraphQL 在處理複雜關聯查詢更具優勢，但 RESTful 更簡單且普及。
誤解：「只有網頁和手機才會用到 API。」澄清：事實上，包括 IoT 裝置、自動化腳本以及企業內部軟體，也都依賴 APIs 作為核心互動方式。例如智慧家電透過 APIs 與雲端進行同步。

What？​

Who？​

When？​

Where？​

Why？​

How？​

🛠️ 建立階段​

🔍 查詢階段​

補充說明​

📌 範例比較​

🧠 延伸／常見誤解​