API 是讓不同軟體依照約定交換資料與功能的介面，手機 App、網站、AI 服務和醫院系統都可能透過它互相溝通。MDN 將 API 定義為軟體內提供功能與規則的介面，Web API 則常以網址、方法和資料格式讓其他程式呼叫。

讀者看到「用 API 串接」時，可以先把它理解成四件事：誰提出請求、要呼叫哪個功能、能帶哪些資料、服務端回傳什麼結果。這個概念也能連到AI模型選型時怎麼看成本、資料與部署；模型選好了，實際接進 App 或企業流程時，往往還要處理 API 的權限、版本與用量。

手機 App、AI 服務、醫療資料與伺服器以 API 介面相互連接的示意圖。

API 是什麼

API 的英文是 Application Programming Interface，中文常譯為應用程式介面。它把一套軟體能提供的功能整理成其他程式可以呼叫的規則，呼叫端不必知道服務內部每一行程式怎麼寫，只要依文件提出符合格式的請求即可。MDN 也把 API 描述成應用程式與其他軟體、硬體或第三方服務互動時使用的功能與規則集合。

App 處理畫面與使用者操作，API 處理程式之間的資料與功能請求。例如天氣 App 可以向氣象服務取得地點資料，電商 App 可以向庫存服務查詢商品，健康 App 則可能在授權後向醫療資料服務請求檢驗結果。API 本身沒有固定的外觀，可能是瀏覽器提供的 Web API，也可能是企業內部服務或硬體控制介面。

API 怎麼運作

以最常見的 HTTP API 為例，流程可以拆成「建立請求、驗證權限、執行服務、回傳結果」四步。HTTP 採用用戶端與伺服器模型，請求由用戶端發出，伺服器處理後送回回應；MDN 的 HTTP 文件列出請求的方法、資源路徑、標頭和內容，以及回應的狀態碼、標頭和回應內容。

元件作用常見例子
方法說明要做的操作GET 讀取、POST 新增或送出
路徑指向服務中的資源或功能/patients/123/labs
標頭傳遞格式、授權與其他控制資訊Authorization、Content-Type
請求內容把要處理的資料送給服務JSON 格式的表單內容
回應告知結果並回傳資料或錯誤200、400、401 加上 JSON

以下是查詢檢驗結果的虛構示意，實際欄位由服務提供者定義：

GET /patients/123/labs?from=2026-01-01 HTTP/1.1
Host: api.example.tw
Authorization: Bearer <access-token>
Accept: application/json

服務端收到後會檢查請求格式與權限，再回傳狀態碼和內容。200 通常表示成功，400 表示請求內容有問題，401 表示尚未通過身分驗證；這些狀態碼屬於 HTTP 回應的一部分，定義可見於 MDN HTTP 回應說明。

HTTP API 請求從用戶端經過授權與伺服器處理，再以狀態碼和資料回傳的流程示意圖。

API、SDK、OpenAPI 有什麼差別

三個名詞常一起出現，工作層次卻不同。API 是服務對外提供的介面規則，SDK 是把呼叫這套介面的常用程式碼、工具和文件打包給開發者使用，OpenAPI 則是描述 HTTP API 的標準格式，讓人和工具能讀懂端點、參數、回應及資料結構。

OpenAPI 規格把自己定位成與程式語言無關的 HTTP API 介面描述，可用來產生文件、協助產生用戶端或伺服器程式，也能降低串接時靠猜測的部分。企業看到「有 API 文件」時，還要確認文件是否包含目前上線版本、錯誤回應、權限方式和範例資料。

健保署的健康存摺 SDK 是台灣的實例。官方資料指出，健保署在 108 年 5 月完成健康存摺資料介接服務，第三方 App 可在使用者授權同意下，選取特定期間的就醫、用藥與檢驗結果等資料供 App 使用。健康存摺 SDK 官方資料說明的 SDK，是協助開發者使用健康存摺資料介接服務的工具，不等於另一套獨立病歷系統。

API、SDK 與 OpenAPI 文件三層分工的示意圖，分別對應服務介面、開發工具和規格文件。

台灣的 API 現況到哪裡

台灣可以看到兩條清楚的 API 使用路線。第一條是政府資料開放，第二條是需要使用者授權的健康資料介接；兩者都用 API 傳遞資料，開放對象、資料範圍和取得條件各自不同。

在政府資料開放平台的格式指引中，API 適合高更新頻率或已有系統即時產製的資料，建議使用 JSON 或 XML，並優先提供符合 OpenAPI 3.0 以上版本的說明文件。平台的資料資源指引也把 API 與 WebService 納入資料品質檢測流程，直接提供 JSON 的服務可依結構化資料流程檢查。

健康資料則多一道授權邊界。健保署公開資料寫明，健康存摺 SDK 可讓第三方 App 介接，民眾在授權同意後選取特定期間資料；健保署 SDK 官方資料可作為介接內容的查核入口，實際申請條件仍要看最新公告。

這代表「有 API」只回答資料能否依規則交換，沒有回答誰能取用、能取哪些欄位、保存多久和能否再利用。政府資料開放平台對 API 服務的定義包含授權利用原則；個別健康資料服務仍須依自身的同意與權限設計處理，不能把公開資料 API 的條件直接套到病歷資料上。政府資料開放平台的欄位指引可查 API 服務的資料集屬性定義。

台灣政府開放資料 API 與需使用者授權的健康資料 API 並列比較的示意圖。

一般人與企業該注意什麼

一般人遇到「連結帳戶」「授權 App 讀取資料」時，先看四個欄位：資料種類、時間範圍、使用目的和撤回方式。OAuth 2.0 的設計讓第三方程式取得受限制的 HTTP 服務存取權，透過 access token 表達範圍、期限等存取屬性，IETF RFC 6749也把資源擁有者、用戶端、授權伺服器和資源伺服器列為流程中的角色。畫面只出現「允許」兩個字時，仍應回到服務條款確認授權內容。

企業導入 API，至少要把以下項目寫進驗收表：

  1. 介面契約：確認網址、方法、欄位型別、必要欄位、錯誤格式和版本退場日期。
  2. 權限設計：讓每個用戶端只拿到任務需要的範圍，設定權杖期限、撤銷流程和金鑰輪替責任。IETF 2025 年 OAuth 安全最佳實務建議使用安全的用戶端驗證、端對端 TLS 和可支援金鑰輪替的設定。
  3. 用量與成本：確認每分鐘請求量、單次資料筆數、逾時、重試、流量上限和第三方服務費用，避免服務故障時讓成本失去控制。
  4. 版本與盤點：保留所有正式與測試端點、文件、版本和停用日期。OWASP 2023 API Security Top 10將錯誤的驗證、物件與功能授權、資源消耗、安全設定、API 盤點及第三方 API 使用列入風險清單，企業可用這份清單安排揭露、修補與退場管理，而非只驗證「能不能連上」。

醫療 AI 還要多驗證資料品質、族群代表性、臨床工作流程和上線後監測。API 回傳 200 只表示這次請求完成，不能直接推出模型診斷正確或臨床結果改善；醫療 AI 導入的五道臨床關卡已把資料、交換、人工覆核與持續監測分開整理。

企業 API 驗收表涵蓋介面契約、權限、用量、版本盤點與醫療 AI 臨床驗證的示意圖。

常見問題

API 跟 SDK 差在哪裡？

API 是軟體提供功能時約定的介面，SDK 是協助開發者呼叫這套介面的工具組。服務可以先有 API，再提供不同程式語言的 SDK，兩者不必視為同一個東西。

API 一定要用 HTTP 嗎？

不一定，API 也可以是程式語言函式、作業系統介面或硬體控制介面。Web API 常使用 HTTP，因為用戶端和伺服器可以用標準方法、網址、標頭和狀態碼交換訊息。MDN 對 HTTP API 的說明可查這條常見路徑。

API 公開就代表任何人都能拿資料嗎？

不代表。公開文件可能只說明介面如何使用，資料仍可能要求登入、授權、用量限制或付費；政府資料開放平台的 API 服務另有資料集授權規則，健康資料 API 還要檢查使用者同意與資料範圍。