API 是什麼？為什麼幾乎所有 App 都在用它？

你每天大概都在用 API，只是很少有人會特別告訴你。早上打開天氣 App，氣溫、降雨機率和未來幾個小時的預報很快就出現在螢幕上；登入一個沒用過的網站，按下「使用 Google 登入」，幾秒之後帳號就建立好了；叫車、查地圖、付款、追蹤包裹，甚至現在常見的 AI 功能，背後也經常有同一種東西在工作。這些 App 並沒有把所有功能都自己做一遍，它們只需要知道，要去哪裡問、該怎麼問，以及對方會怎麼回答。這套讓不同程式能彼此溝通的規則，就是 API。

API 的全名是 Application Programming Interface，中文通常翻成「應用程式介面」。名字看起來有點硬，但概念其實沒有那麼複雜。假設一個天氣 App 想知道台北現在幾度，它不需要知道氣象服務的資料庫放在哪裡，也不需要知道對方怎麼整理測站資料、怎麼計算預報。它只要照規定送出一個請求，例如「我要台北目前的天氣」，對方收到之後處理，再把結果送回來。對 App 來說，中間那些細節可以全部不知道，只要雙方對「怎麼說話」這件事有共識就夠了。

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

這個「送出去的要求」通常叫做 request，收到的結果叫做 response。如果把整段流程壓到最簡單，大概就是下面這樣。你的 App 先提出要求，服務端處理完，再把結果送回來。API 本身不是某個神祕的黑盒子，它比較像雙方事先談好的溝通方式。

回來的東西也不一定是人類看得舒服的樣子。天氣服務可能只回一小段資料：

{
  "city": "Taipei",
  "temperature": 28,
  "rain_probability": 40
}

這種格式叫 JSON。它沒有漂亮的圖示，也沒有排版，因為它本來就不是主要給人看的，而是給程式讀的。App 收到之後，才決定要把 28°C 放在哪裡、要不要畫一朵雲、降雨機率要用文字還是圖表表示。同一份資料，可以被手機 App 拿去做天氣卡片，也可以被網站拿去做圖表，甚至可以被另一個程式拿去觸發「下雨就提醒我帶傘」的自動化。API 負責的是資料怎麼進出，不是最後的畫面要長什麼樣子。

Endpoint 是入口，API 不是資料庫

如果一個服務能做很多事，通常也不會只有一個入口。查天氣、查使用者、建立訂單、刪除資料，可能各自有不同的位置。這些明確的入口常被叫做 endpoint。所以工程師在講「這支 API 要打哪個 endpoint」，通常不是在講什麼很神祕的東西，只是在問：我要去哪個入口，才能做我要做的事情。

API 也很常跟資料庫混在一起講，實際上兩者不是同一回事。資料庫負責存東西，API 則比較像外面的人和系統內部溝通時經過的入口。一個常見的網站大概可以畫成：

你在螢幕上看到的按鈕、表單和頁面屬於前端；帳號、成績、貼文、訂單這些資料可能放在資料庫裡；API 和後端則站在中間，決定這次要求合不合理、這個人有沒有權限，以及到底該拿哪些資料回去。

為什麼不讓前端直接碰資料庫？

如果前端可以直接進資料庫，很多事情會立刻變得麻煩。假設一個成績系統只是把「編輯成績」的按鈕藏起來，就認為學生不能改成績，那幾乎等於沒有保護。真正的限制應該放在後端：學生提出修改要求時，系統要直接拒絕；老師提出相同要求時，再確認他是不是這個班的老師。API 在這裡不只是把資料送來送去，也成了權限和規則真正執行的地方。

這也是為什麼有些 API 可以公開使用，有些不行。公開 API 可能讓所有開發者查天氣、地址或匯率；有些 API 需要 API key，確認是誰在使用；還有一些根本只服務某個網站自己的前端，從來沒打算讓外面的人碰。看到「這個服務有 API」，不代表它把整個系統打開給所有人，只代表它有一套程式可以使用的介面。

AI API 其實也沒有比較神祕

AI 服務也是一樣。當一個程式呼叫模型 API，它可能只是把一段文字送出去，再收到模型產生的結果。OpenAI、Gemini 或其他模型的 API 看起來很新，但底層概念並沒有特別不同。程式照規格送 request，服務處理，再回 response。AI 只是 API 能連到的其中一種服務，地圖、付款、登入、物流和天氣早就在做相同的事情。

API 真正重要的地方，不是它有多複雜，而是它讓不同系統可以在不理解彼此全部內部細節的情況下合作。一個 App 不需要知道 Google 地圖怎麼建立全球道路資料，也不需要知道付款平台怎麼跟銀行溝通；只要對方願意留下一個穩定、清楚的入口，其他程式就能站在上面繼續做自己的東西。