API 介接
API 是前端與後端之間的『點餐櫃台』,規定雙方如何溝通。
屬於路線新手路線
一句話解釋
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 →