API 是什麼？API 是 Application Programming Interface 的縮寫，中文常譯為應用程式介面，指一套讓軟體與軟體互動的功能與規則：人透過畫面操作系統，程式則透過 API 向另一個系統送出請求、取回回應。官網把訂單送進出貨系統、App 向後台查詢會員點數、網站嵌入地圖，背後都是 API。企業系統靠 API 交換資料，可以減少人工重複輸入，讓不同廠商的系統依約定好的格式協同運作，前提是管好金鑰、權限與錯誤處理。
API 的意思：程式之間約定好的介面
MDN 對 API 的說明是：存在於軟體內、讓其他軟體能與它互動的一組功能與規則，相對於給人使用的操作畫面；它可以看成提供 API 的應用程式，與其他軟體或硬體之間的一份約定。約定的內容包括可以要求什麼、要用什麼格式提出、會得到什麼回應。
可以把它想成餐廳的點餐單：點餐單列出能點的品項與點法，客人不需要知道廚房怎麼運作；系統也只需要照 API 規定的方式提出要求，不必知道對方內部的程式與資料庫。API 有很多種，瀏覽器提供給網頁使用的定位功能是 API，系統之間透過網路交換資料的介面也是 API，本文談的是後者。
一次 API 呼叫怎麼運作：請求與回應
以建立在 HTTP 之上的 API 為例，HTTP 是用戶端與伺服器之間的協定，由用戶端發出請求。一個請求包含 HTTP 方法（例如取得資料用 GET、送出資料用 POST）、資源路徑、選用的標頭，以及部分方法會帶的本文；伺服器的回應則包含狀態碼、標頭與選用的本文。資料常用 JSON 這種資料交換格式，許多程式語言都支援。
狀態碼分成資訊、成功、重新導向、用戶端錯誤與伺服器錯誤五類，串接時常看到的有：
| 狀態碼 | 意思 | 常見原因 |
|---|---|---|
| 200 | 請求成功 | 依方法不同，回應本文帶回資料或處理結果 |
| 401 | 未通過身分驗證 | 金鑰或權杖缺漏、錯誤或已失效 |
| 403 | 伺服器理解請求但拒絕處理，重新驗證也無效 | 帳號權限不足 |
| 404 | 找不到請求的資源 | 路徑錯誤，或端點正確但該筆資料不存在 |
| 429 | 一段時間內請求過多 | 超過對方設定的頻率限制 |
REST、Webhook 與其他常見形式
REST 是一組軟體架構的設計限制。實務上，以 HTTP 提供的 API 常被通稱為 RESTful API，即使不一定符合全部限制；入門時可以把 REST API 理解成能用標準網頁工具與函式庫呼叫的 HTTP 服務。
Webhook 則是反過來的方向：不是你去問對方，而是事件發生時由對方通知你。以 LINE 的 Messaging API 為例，每當使用者把 LINE 官方帳號加為好友或傳送訊息，LINE 平台就會對你設定的伺服器網址發出含事件內容的 HTTP POST 請求，官方文件也建議處理前先驗證請求標頭中的簽章。這種方式適合需要即時反應的情境；定期整批同步的資料，則可以改用排程呼叫或檔案交換。
企業系統為什麼要靠 API 交換資料
- 減少重複輸入：表單資料直接寫進客戶管理系統，不必再由人工複製貼上，也少了抄錯的機會。
- 只開放需要的部分：對方只能透過 API 存取約定的功能與欄位，不必把整個資料庫交出去。
- 資料保持一致：訂單、庫存、會員點數以單一系統為準，其他系統透過 API 讀取。
- 換系統較有彈性：只要新系統提供相同用途的 API，周邊系統調整串接即可，不必全部重來。
官網表單接到客戶關係管理系統，是容易理解的例子，可參考CRM 的功能與導入準備。要注意的是，個資法所稱的「處理」包含個人資料的連結或內部傳送，系統之間傳遞會員資料時，傳送範圍與目的要事先規劃，細節請以主管機關公告或專業意見為準。實際要串接時怎麼規劃，可參考API串接的流程與規格確認。
日常看得到的 API 例子
- 網站與 App 裡的地圖：取得使用者位置後，搭配 Google 地圖平台的 API 在地圖上標出附近門市。Google 地圖平台預設採即付即用定價，呼叫量會反映在費用上，另提供含一定呼叫量的訂閱方案。
- LINE 官方帳號的自動回覆：透過 Messaging API 接收好友訊息事件，再由自家系統查詢訂單或預約後回覆。
- 用 Google 帳號登入：Google API 以 OAuth 進行驗證與授權，使用者登入後會被詢問是否授予應用程式要求的權限，取得的存取權杖只適用於當初要求的範圍。
- App 推播通知：iOS 的推播是公司伺服器把通知請求轉給 Apple 推播通知服務，再由它送到使用者裝置。
API Key 與權限的基本觀念
很多 API 要求在請求中附上 API Key（API 金鑰）。以 Google Cloud 的說明為例，API 金鑰的作用是把請求和專案建立關聯，以便計費與配額管理；標準 API 金鑰不會驗證主體，也就是無法證明是誰在呼叫。因此金鑰要當成密碼管理：
- 不要把金鑰直接寫在原始碼或存放在程式碼存放區，以免被攔截或竊取。
- 同時設定 API 限制與應用程式限制，金鑰外流時能縮小影響範圍。
- 定期建立新金鑰、更新程式後刪除舊金鑰，只保留使用中的金鑰。
需要代表使用者存取資料時，常用 OAuth：它讓第三方應用程式取得對 HTTP 服務的有限存取權。建議企業依用途分開申請金鑰或帳號、只開放必要權限，合作廠商結束合作時，一併停用對方使用的金鑰。
常見問題
API 全名是什麼？
API 是 Application Programming Interface 的縮寫，中文常譯為應用程式介面。它不是某一套軟體，而是程式之間互相呼叫功能、交換資料時要遵守的約定。
不會寫程式也能用 API 嗎？
有些雲端服務在後台提供現成的串接設定，背後使用的就是 API，照指示設定即可運作。需要客製的欄位對應、流程判斷或錯誤處理時，仍需要工程師依 API 文件開發。
使用 API 要付費嗎？
依提供者而定，有的免費、有的按用量計費，也有的包含在訂閱方案內。使用前先看清楚計費方式、配額與服務條款，按用量計費的服務建議設定預算提醒。
API Key 外洩了怎麼辦？
先停用或刪除外洩的金鑰，建立新金鑰並更新程式，再檢查用量紀錄是否有異常呼叫。之後把金鑰從原始碼移到安全的設定位置，並加上使用限制。
公司官網需要 API 嗎？
只展示內容的官網不一定需要。若表單要寫入客戶管理系統、頁面要顯示即時庫存或預約時段，或要和金流、物流交換資料，就需要透過 API 串接。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
評估系統之間要怎麼交換資料時，可以先列出要互通的系統、資料項目與更新頻率，並向各系統廠商索取 API 文件。京采的網頁設計服務可以協助需求釐清、評估對方 API 的可行性，並開發官網、後台與既有系統之間的 API 串接；歡迎與我們聯繫討論。
