VCA

API 介接

API 是前端與後端之間的『點餐櫃台』,規定雙方如何溝通。

更新於 閱讀約 1 分鐘編輯方針#系統基礎#溝通#契約
屬於路線新手路線

一句話解釋

API 是系統之間溝通的『約定好的窗口』,規定要怎麼問、會得到什麼答案。

白話文說明

API(應用程式介面) 就是兩個系統之間「講好的溝通方式」。前端想要資料,不能直接闖進後端的廚房,而是走 API 這個櫃台:照規定的格式提出請求,後端照規定的格式回覆。

好的 API 有清楚的契約:請求要帶什麼、回應長什麼樣、出錯時回什麼代碼。契約清楚,前後端就能各自獨立開發,也方便 AI 幫你產生正確的串接程式。

架構圖

運作流程

好契約與壞契約

一個 API 好不好串接,差別就在契約。

  • 好契約清楚(請求與回應長什麼樣都寫明)、穩定(不會在你沒注意時偷偷改掉)、有文件(每個欄位代表什麼都查得到)、有版本(新版走 /v2/,舊的 /v1/ 照常運作)。
  • 壞契約毫無預警就變動,把依賴它的東西全弄壞;還會洩漏內部細節,例如直接吐出資料庫欄位或錯誤堆疊;又沒有文件,只能靠一再試誤去摸清它的行為。

常見誤解:以為 API 就等於後端。API 是講好的介面(契約),後端是它背後的實作。只要契約不變,你可以重寫後端——換語言、換資料庫——前端完全不會察覺。

重點整理

  • API=系統間「講好的溝通窗口」。
  • 重點在契約:請求格式、回應格式、錯誤代碼。
  • 契約變更要做版本(例如 /v1/、/v2/),避免一改全壞。

生活化比喻

API 像餐廳的點餐櫃台:你照 menu 點(請求),廚房照單做好端出(回應),雙方有共同的規則。

優勢

  • 讓不同系統可以乾淨地對接
  • 同一套 API 可同時服務網頁與 App
  • 有明確契約,AI 與人都容易協作

缺點

  • 契約一改,雙方都要跟著改(要做版本管理)
  • 設計不良會造成難以維護的耦合

適用場景

  • 前後端分離的應用
  • 要開放給第三方串接的服務

不適用場景

  • 完全沒有資料交換的純靜態頁

新手評分卡

新手推薦度
4/5
學習成本(分數越高=成本越高)
3/5
市場需求
5/5
AI 生成友善度
5/5

常見問題

API 到底是什麼?

它是系統之間的「點餐櫃台」:你按約定的格式送出請求,對方按約定回你資料,雙方都不用知道彼此內部怎麼運作。

前端可以直接連資料庫,不用 API 嗎?

強烈不建議。那等於把倉庫鑰匙交給每個客人;API 是中間關卡,負責驗證身分與權限、過濾不該外流的資料。

REST 和 GraphQL 我該用哪個?

新手與多數專案用 REST 就夠,簡單直觀;當前端需要靈活組合大量關聯資料時,再考慮 GraphQL,別為了流行而提前採用。

新手路線 的下一步: DNS