API 是什麼？為什麼老闆也該懂這個技術名詞

場景：你和外包開發團隊開會，工程師說「金流的部分，我們用 API 串接綠界，Webhook 會回傳付款狀態」。你看了一眼旁邊的 PM，兩人交換了一個「聽起來好像很厲害但我完全不懂」的眼神，然後你點了點頭，說「好，那就照你說的做」。

這個場景，幾乎每個非技術背景的老闆都經歷過。你不是不聰明，只是從來沒有人用你聽得懂的方式解釋過 API 是什麼。

這篇文章就是那個解釋。讀完之後，你不會變成工程師，但你會知道：API 到底在做什麼、它為什麼會影響你的報價單、出問題的時候該問誰，以及驗收時該檢查哪些安全項目。這些知識，會讓你在技術會議裡不再只是「點頭的那個人」。

用「服務生」來理解 API

API 的全名是 Application Programming Interface，中文叫「應用程式介面」。但這個翻譯對非工程師來說等於沒翻。所以，讓我們用一個所有人都懂的場景——餐廳——來解釋。

想像你走進一家餐廳。你（前端 / 使用者）坐在座位上，廚房（後端伺服器 / 資料庫）在你看不到的地方。你不能直接跑進廚房跟廚師說「給我一碗牛肉麵」，你需要透過服務生來點餐。

這個服務生就是 API。

服務生的工作流程是：

1. 接收你的點餐（Request / 請求）——你說「我要一碗招牌牛肉麵，少辣」

2. 把訂單傳到廚房（傳送到伺服器）——服務生不會改你的訂單，他忠實地傳遞

3. 廚房做好之後，服務生把餐點端回來（Response / 回應）——你拿到一碗熱騰騰的牛肉麵

如果廚房沒有這道菜，服務生會回來跟你說「抱歉，今天牛肉麵賣完了」——這就是 API 回傳的錯誤訊息（Error）。

為什麼不讓你直接進廚房？因為安全性和標準化。廚房裡有刀有火，讓每個客人自己進去很危險（資料庫被亂改）。透過服務生（API），餐廳可以控制誰能點什麼、一次最多點幾道、哪些菜需要加價——這些就是 API 的權限控制和規格限制。

你的系統到處都在用 API

你可能覺得 API 聽起來很技術，跟自己的事業沒有關係。但事實是，你每天用的系統幾乎都在背後透過 API 溝通。這裡列幾個老闆最常碰到的場景：

用 Google 帳號登入：你的官網讓客戶用 Google 帳號登入，背後就是呼叫 Google 的 OAuth API。你的系統不需要自己管密碼，Google 負責驗證身分，然後透過 API 告訴你的系統「這個人是合法的」。

金流串接：客戶在你的網站刷卡付錢，你的系統透過 API 把訂單金額傳給綠界或藍新，金流商處理完付款後再透過 API 通知你的系統「錢收到了」。你不需要自己處理信用卡號碼。

物流追蹤：出貨後你的系統透過 API 把包裹資訊傳給物流商，客戶查詢進度時，你的系統再透過 API 向物流商拿最新狀態。

LINE 通知：客戶下單後收到 LINE 訊息通知，是你的系統透過 LINE Messaging API 自動發送的。

ERP / CRM 同步：你的電商訂單自動匯入 ERP 系統，靠的也是兩個系統之間的 API 串接。

下面這張圖，展示了一個典型的電商網站背後 API 串接的全景。你會發現，你的系統其實是一個靠 API 連接起來的生態系：

看到這張圖，你應該能理解為什麼工程師常說「串接」這個詞——因為你的系統真的是被一條一條 API 串在一起的。任何一條線斷掉，對應的功能就會出問題。這也是為什麼API 的穩定性直接影響你的營收。

REST API、GraphQL、Webhook——老闆需要知道的三種類型

工程師提案的時候，可能會冒出這些名詞。你不需要知道技術細節，但需要知道它們的差別，才不會在報價和時程上被當韭菜割。

REST API：最主流的溝通方式

REST API 就像傳統餐廳——你看菜單點菜，一次點一道，服務生一趟一趟送。它是目前最主流的 API 類型，大約 80% 的系統串接都是用 REST。優點是簡單、標準化、大部分工程師都會。缺點是如果你一次需要很多資料，可能要呼叫好幾次。

GraphQL：一次問到飽

GraphQL 像是自助餐——你自己決定要拿什麼、拿多少。一次請求就能拿到你需要的所有資料，不會多也不會少。適合資料關聯性複雜的系統（像是社群平台、大型電商），但學習門檻比 REST 高，不是所有工程師都熟。

Webhook：「別問我，有事我會通知你」

前面兩種都是「你主動問」，Webhook 則是「對方主動通知你」。就像你跟餐廳說「菜做好了打電話給我」，你就不用一直站在出餐口等。金流串接裡的「付款完成通知」就是典型的 Webhook。客戶付完錢，綠界主動通知你的系統，而不是你的系統每秒鐘去問「付了沒？付了沒？」

實務上的建議：如果工程師跟你說要用 GraphQL，問他一句「為什麼不用 REST 就好？」如果他能清楚說出理由（例如前端需要高度彈性查詢），那就合理。如果說不出來，可能只是想練新技術——這不應該算在你的專案費用裡。

延伸閱讀：如果你還不太清楚前端和後端的差別，建議先看這篇 前端、後端、全端差在哪？，會幫助你更容易理解 API 的運作脈絡。

API 串接出問題時，怎麼判斷是誰的責任？

這是老闆最頭痛的問題之一。系統出問題的時候，前端工程師說「問題出在後端 API 沒回，不是我的問題」，後端說「問題出在第三方 API 掛了，不是我的問題」，第三方說「我們系統一切正常，問題出在你們呼叫方式不對」。踢皮球大賽開始。

身為老闆，你不需要自己除錯，但你需要知道怎麼問對問題：

判斷框架：三個層級

第一層：前端問題——使用者看到的畫面有問題（按鈕按不了、頁面空白、資料顯示錯誤）。問前端工程師：「API 有回傳資料嗎？回傳的資料是什麼？」如果 API 有正確回傳資料，但畫面顯示不對，那就是前端的問題。

第二層：後端 / API 問題——前端確認「API 沒有回傳資料」或「回傳錯誤」。這時候問後端：「API 的 Log（日誌）顯示什麼？是我們的程式邏輯錯，還是對第三方的請求失敗了？」

第三層：第三方 API 問題——後端確認「我們的請求有送出去，但對方回傳錯誤」。這時候去查第三方的狀態頁（大部分服務都有，例如 status.ecpay.com.tw），或直接聯繫第三方客服。

關鍵問句（開會時直接問）：「請打開 API 的 Log，讓我看到請求和回應的時間戳記、狀態碼和錯誤訊息。」工程師如果答不出來，表示他們沒有做好 API 的日誌紀錄——這本身就是一個應該在開發階段就要求的品質標準。

如果你正在選擇開發公司，建議參考這篇 如何挑選軟體開發公司，裡面有評估技術能力的實用清單。

API 對你的報價單有什麼影響？

打開外包商的報價單，你會看到「金流串接」「物流串接」「第三方登入」這些項目。每一項背後就是一組 API 串接的工作。API 串接的費用差異很大，理解背後的成本結構，能幫你判斷報價是否合理。

API 串接費用的四個變數

1. 第三方 API 的文件品質：API 文件寫得好的服務商（例如 Stripe），串接起來又快又穩，工時少費用低。文件寫得爛的（不點名，但台灣很多老牌金流……），工程師要花大量時間試錯，工時高費用就高。

2. 串接的複雜度：「只是呼叫一支 API 查資料」和「要處理非同步回呼、錯誤重試、資料對帳」是完全不同等級的工作量。前者可能只要 4-8 小時，後者可能需要 40-80 小時。

3. 是否需要處理異常狀況：金流 API 真正棘手的是「付款失敗」「逾時」「重複扣款」這些異常，「付款成功」反而是最簡單的情境。一個負責任的工程師會把所有可能的錯誤路徑都處理好——這需要時間，也反映在報價裡。

4. API 的使用費用：有些 API 是免費的，有些按次計費（例如每次呼叫 0.01 元），有些按月訂閱。這些費用是營運成本，開發完之後每個月都要付。報價單裡不一定會列，但你應該主動問。

想更完整地理解軟體開發的費用結構，推薦閱讀 軟體開發費用拆解，那篇文章把報價單的每個項目都講得很清楚。

API 安全——老闆該問的 5 個問題

API 安全其實是老闆的事，並非只有工程師要管。為什麼？因為 API 如果被攻破，洩漏的是你客戶的個資，負法律責任的是你的公司。2024 年台灣個資法修法後，罰則已經大幅提高。

你不需要懂技術細節，但驗收系統的時候，這五個問題一定要問：

問題一：API 有做身分驗證嗎？

就像餐廳不會讓路人走進廚房一樣，你的 API 不應該讓任何人都能呼叫。最基本的身分驗證是 API Key（一組密碼），更安全的是 OAuth 2.0 或 JWT Token。問工程師：「我們的 API 用什麼驗證機制？」

問題二：敏感資料有加密嗎？

客戶的密碼、信用卡號、身分證字號，在 API 傳輸過程中一定要加密。最基本的是全站 HTTPS（SSL 憑證），進階的是敏感欄位額外加密。問工程師：「我們的 API 傳輸是全程 HTTPS 嗎？密碼是明文還是雜湊儲存？」

問題三：有做速率限制嗎？

如果有人惡意對你的 API 每秒發送一萬次請求，你的伺服器就會當機。速率限制（Rate Limiting）就是設定「每個用戶每分鐘最多呼叫幾次」。問工程師：「我們有設 Rate Limit 嗎？設多少？」

問題四：API 金鑰放在哪裡？

API Key 就是你家的鑰匙。如果工程師把 API Key 寫死在前端程式碼裡（任何人按 F12 就看得到），那等於把鑰匙掛在門口。正確做法是放在後端的環境變數裡。問工程師：「我們的 API Key 存在哪裡？有沒有寫進版本控制？」如果你想進一步了解版本控制的概念，可以參考 什麼是 Git？版本控制入門指南。

問題五：有 API 異常監控嗎？

API 被攻擊或異常的時候，你應該第一時間收到通知，而不是等客戶打電話來罵才知道。問工程師：「我們有設 API 監控嗎？異常的時候會通知誰？多快能收到警報？」

以上五個問題不需要技術背景就能問出口，但能幫你在資安事件發生前就建好防線。

常見問題

下一步：讓你的系統串接做對

讀到這裡，你已經具備了和工程師討論 API 的基本知識。你知道 API 就是系統之間的服務生，你知道 REST、GraphQL、Webhook 的差別，你知道報價單上 API 串接費用的合理範圍，你也知道驗收時該問哪些安全問題。

如果你正在規劃新系統、或是現有系統需要串接第三方服務，歡迎和我們聊聊。恆遠的開發團隊擅長各種 API 串接——從金流、物流到 ERP、CRM 整合，我們會用你聽得懂的方式，幫你把技術需求理清楚，給你一份看得懂的報價單。

免費諮詢：跟我們聊聊你的 API 串接需求