API 是什麼？用最白話的方式解釋

用「餐廳點餐」秒懂

你去餐廳不會直接衝進廚房煮菜。你透過「服務生」點餐：你照菜單給出明確的請求，服務生傳進廚房，再把做好的菜端回來給你。

API 就是那個服務生。你（一個程式）不用懂廚房（另一個系統）內部怎麼運作，只要照「菜單」（也就是 API 的使用說明，一般叫「API 文件」）提出請求，就能拿到你要的結果。

這個比喻之所以好用，是因為它同時解釋了 API 的三個特性：你只能點菜單上有的東西（API 沒開放的功能你就是拿不到）、你得照規矩點（格式寫錯就會被退回）、廚房怎麼煮不關你的事（對方改內部作法，只要菜單不變，你的程式就不用改）。

API 到底是什麼

API 全名 Application Programming Interface。拆開看：Application 是「應用程式」（也就是各種軟體、App）、Interface 是「介面／接口」——合起來就是「應用程式之間的接口」，中文常稱「應用程式介面」。

它規定了三件事：你可以向某個系統「請求什麼」、要「怎麼請求」、以及會「拿回什麼」。程式與程式之間，就靠這套規則互相呼叫。你想用別人的功能（金流、地圖、AI），不必自己重做，照它的 API 規則去要就好。

你每天都在用的 API（只是沒發現）

• 用 Google 或 LINE 帳號登入別的網站 —— 那個網站在背後呼叫 Google／LINE 的登入 API
• 叫車、外送 App 上顯示的地圖 —— 用地圖服務商的地圖 API
• 線上刷卡結帳 —— 網站呼叫金流公司的金流 API 來處理付款
• 看即時匯率、天氣 —— 從對應的資料 API 拿最新數字
• 電商後台顯示「已出貨、物流單號 xxx」—— 系統向物流公司的 API 查詢配送進度

一次 API 呼叫，實際上發生了什麼

把「點餐」拆細一點，你就能看懂技術文件在講什麼。一次呼叫大致是四個部分：

• 端點（endpoint）：要去哪裡問。長得像一個網址，例如 https://api.某服務.com/orders。不同端點對應不同功能，就像菜單上不同的品項
• 請求方法（method）：你要做什麼。最常見四種：GET＝我要看資料、POST＝我要新增一筆、PUT／PATCH＝我要修改、DELETE＝我要刪除。看到工程師說「打一個 GET」，意思就是「去讀一筆資料」
• 參數與內容（parameters / body）：細節條件。例如「我要查 2026 年 7 月的訂單」「我要新增這位客人的資料」
• 回應（response）：對方回給你的東西。通常包含一個「狀態碼」（告訴你成功還失敗）和一包資料

資料長怎樣？認識一下 JSON

API 回給程式的資料，最常見的格式叫 JSON（讀作「Jason」）。你不用會寫，但看到這個字別怕——它其實就是一種「電腦之間好讀好傳的資料寫法」，長得像一堆「欄位名稱：值」的配對。

舉例，一個天氣 API 可能回：{"城市": "台北", "溫度": 28, "天氣": "晴"}。人看得懂，程式也好處理。所以「API 回傳 JSON」白話就是「API 用這種整齊的格式把資料吐給程式」。

為什麼要有固定格式？因為程式不像人會「看情況理解」。格式一致，程式才能穩定地把「溫度」這個欄位抓出來用。你之後看到工程師在意「欄位名稱有沒有改」，就是這個原因——欄位一改，接的那一端就會壞掉。

串接出錯時，那些數字代表什麼

串 API 最常見的挫折，是拿到一串看不懂的錯誤。其實常見的就那幾種，先認得它們，你就能自己判斷「是誰的問題」：

• 400（請求有問題）：你送的格式或參數不對。是你這邊要改
• 401（沒帶身分）：沒附上金鑰，或金鑰無效。檢查金鑰有沒有設定好
• 403（身分對，但不准）：你確實是你，但這個帳號沒有這個權限。要去對方後台開權限或升級方案
• 404（找不到）：端點網址打錯，或那筆資料不存在
• 429（太頻繁）：你在短時間內呼叫太多次，被限流了。要放慢速度或分批處理
• 500 開頭（對方壞了）：對方系統出錯，不是你的問題。通常等一下重試，或去看對方的服務狀態頁

常聽到的相關名詞，一次搞懂

• API key（金鑰）：一串證明「這是我」的密碼字串，用來辨識身分與計費。等同鑰匙，絕不能外流（詳見金鑰安全那篇）
• REST API：目前最普遍的一種 API 設計風格。你聽到「這是 REST API」，白話就是「它照大家熟悉的那套常規在設計」，不用想太複雜
• SDK（軟體開發套件）：對方幫你包好的工具箱，讓工程師少寫很多重複的程式。有 SDK 通常代表串接會比較快
• rate limit（速率限制）：對方規定你每分鐘／每天最多能呼叫幾次，避免被濫用。規劃自動化時一定要先看這個數字
• 沙盒（sandbox）／測試環境：一個假的練習場，讓你先用假資料測試，不會真的扣款、真的寄信。上線前務必先在這裡測
• webhook：方向相反的機制——不是你去問，而是對方有事主動通知你。常和 API 搭配使用

對中小企業／創業者的意義

API 是「讓系統彼此連起來、能自動化」的關鍵。電商訂單自動同步到 ERP（企業內部管進出貨、帳務的系統）、LINE 自動回覆客戶、AI 自動讀你的報表 —— 這些「自動化」本質上都是用 API 把 A 系統接到 B 系統。

所以當工程師問「這個有沒有 API」，意思其實是「這個系統能不能被別的程式串接、能不能自動化」。有 API＝可自動化、可擴充；沒有 API＝很多事只能靠人工複製貼上。這一點常常決定一個工具「好不好接、能不能長出自動化」。

實務上更關鍵的是：這件事應該在你「選工具」的時候就問，而不是等要自動化了才發現接不上。換一套已經全公司在用的系統，成本遠高於一開始就挑一個有 API 的。

選工具前，關於 API 該問的 5 個問題

不用懂技術也能問。把這幾題丟給廠商業務或工程師，答案就足以判斷這個工具日後好不好自動化：

• 有沒有公開的 API 文件？ 願意公開文件，通常代表它認真支援串接。連文件都要簽約才給，之後多半麻煩
• API 是所有方案都能用，還是要升級到某個等級？ 很多 SaaS 把 API 鎖在較高的方案，這是隱藏成本
• 呼叫次數有沒有限制？怎麼收費？ 對應上面的 rate limit。量大時這會直接變成月費
• 我要的那幾件事，API 真的做得到嗎？ 有 API ≠ 什麼都能做。把你真正想自動化的動作逐條對照文件
• 資料能不能完整匯出？ 這是退場的保險。哪天要換系統，能不能把自己的資料帶走

一鍵複製：請 AI 幫你評估一個工具的串接可行性

把工具名稱和你想自動化的事填進去，讓 AI 先幫你做一輪功課。它的回答仍須以官方文件為準——請它附上文件連結，你自己點進去確認。

三個常見的誤會

• 「有 API 就等於能做任何事」：不對。API 只開放對方願意開放的功能。很多系統的 API 只能讀不能寫，或只開放一部分資料。一定要對照文件逐條確認
• 「串 API 一定要工程師」：不一定。Zapier、Make 這類自動化平台已經把上百種常見工具的 API 包成拖拉式的設定，很多情境不用寫一行程式。真正需要高度客製時才找工程師
• 「API 免費」：不一定。有些免費、有些按呼叫次數或資料量計費。而且「免費額度」用完之後的價格，常常才是真正的成本。串接前先把計費方式看清楚