從資料庫到 API：後端怎麼讓前端拿到想要的資料？

當你打開一個網站、使用一個 App，例如看到網頁上的商品列表、個人資訊、留言紀錄……你有沒有想過：這些資料是從哪裡來的？

這些資料，大多不是寫死在程式碼裡，而是由「後端」從「資料庫」裡抓出來，再透過一種叫做 API 的介面，傳送給「前端」顯示出來。

那麼，後端到底怎麼做到的？資料存在什麼地方？API 又是什麼？這篇文章將用淺顯易懂的方式，帶你從資料庫一路理解到 API，幫助你建立起基本的後端資料處理概念。

資料庫是什麼？為什麼它是現代應用程式的核心？

要回答這些問題，我們得先從「資料存放的地方」說起。

想像一下：當你在購物網站上看到上千件商品、在社群平台上滑過無數則貼文，這些內容不可能一筆一筆寫死在程式碼裡。它們其實都被集中存放在一個專門管理資料的地方——資料庫。

後端程式就像是一位倉庫管理員，負責從資料庫裡把資料取出來、整理好，再透過 API 這條傳輸通道，送到前端讓使用者看見。

那麼，資料庫到底是什麼？它又是怎麼運作的？

資料庫（Database）是一套集中儲存與管理資料的系統，專門設計來處理大量資料的新增、查詢、修改、刪除。

這四種操作合稱為 CRUD，分別是：

• Create：新增資料（例如新增一筆訂單）
• Read：讀取資料（例如查詢使用者清單）
• Update：修改資料（例如更新會員電話）
• Delete：刪除資料（例如移除一筆留言）

你可以把資料庫想像成一個超大型的「數位檔案櫃」，裡面有一堆資料夾（資料表），每一個資料夾又有很多紙張（資料列），紙上寫的是一筆筆完整的資料記錄，例如：

每一欄就是一個資料「欄位」或「欄（Column）」，而每一列就是一筆資料「記錄（Row）」。

資料庫的強大功能有哪些？

與其說它只是存資料的地方，不如說它是整個應用系統的「大腦」，因為它能做到的遠不只是儲存：

✅ 1. 儲存大量資料沒問題

• 資料庫可以處理成千上萬甚至上億筆資料，並保持高效率。
• 像 YouTube、Instagram、Line 都是靠資料庫在處理龐大使用者資料與內容。

✅ 2. 可以快速查詢與篩選資料

• 只要輸入一段 SQL 語法，就可以從幾萬筆資料中找出「昨天註冊的所有台北人」或「花最多錢的前10名使用者」。

✅ 3. 可以設定資料格式限制

• 你可以規定「信箱欄位」只能填寫 email 格式，防止錯誤輸入。
• 也可以限制「年齡」只能填寫數字，避免資料混亂。

✅ 4. 支援多人同時存取

• 多人使用時不會互相覆蓋資料，系統會自動協調存取順序。
• 適用於即時聊天室、購物網站等多人同時操作的情境。

✅ 5. 搭配備份與安全機制，保障資料不遺失

• 可以定期備份資料，避免系統故障導致資料消失。
• 支援權限控管，防止未授權的人員查看或竄改資料。

📌 總結一句話：資料庫是幫助我們「持久、安全、有組織地」儲存與操作資料的核心工具。

資料庫可以放在哪裡？

資料庫不一定要放在你自己的電腦裡，它有不同的部署方式，適用於不同規模與需求的專案。

放在本地伺服器（Local Server）

這種方式就像你在公司或學校自己架設一台伺服器，上面安裝好資料庫軟體，全部自己掌控。

優點：

• 所有資料完全掌握在自己手上
• 可以依照需求客製化設定與維護
• 適合內部系統或大型企業自己管理

缺點：

• 需要自己處理硬體、系統維運、備份、資安
• 成本較高，維護人力需求大

放在雲端資料庫服務（Cloud Database）

現在越來越多開發者會選擇使用雲端資料庫平台，例如：

• AWS RDS（Amazon）
• Firebase Firestore（Google）
• Supabase（開源選擇，類似 Firebase）
• PlanetScale（現代化 MySQL 服務）

你只要註冊帳號、點幾下，就能開好一個資料庫，而且系統會幫你處理：

• 備份
• 安全性
• 維運
• 自動擴容（流量大時自動加強效能）

優點：

• 快速、方便、穩定
• 不需自己維護硬體
• 適合中小型專案或初學者練習

缺點：

• 需要連網才可使用
• 根據方案可能會有費用

常見的資料庫種類有哪些？

根據資料的儲存形式與使用情境不同，資料庫大致可以分成以下三種類型：

關聯式資料庫（Relational Database）

這是最傳統、最常見的資料庫類型，也是學習後端開發時最先接觸的種類。

• 用「表格」儲存資料（就像 Excel）
• 各資料表之間可以透過「鍵值」建立關聯，例如：使用者有多個訂單
• 使用 SQL（Structured Query Language）來查詢資料

適合情境：

• 電商網站（商品、訂單、用戶）
• 公司內部系統（人事、庫存、報表）

常見工具：
MySQL、PostgreSQL、SQLite、SQL Server

非關聯式資料庫（NoSQL Database）

NoSQL 意思是「Not Only SQL」，代表不再只是表格形式的資料庫，常見的資料結構是文件（JSON 格式）或鍵值對（key-value）。

• 不需要固定欄位結構，彈性大
• 儲存方式更接近物件導向程式的資料格式
• 不一定使用 SQL 查詢語言

適合情境：

• 即時聊天系統
• 大數據分析平台
• 快速開發的原型系統（Prototype）

常見工具：
MongoDB、Firebase Firestore、CouchDB、Redis（鍵值型）

輕量級資料庫（Embedded / File-based）

這類資料庫通常會直接儲存在一個檔案中，不需要額外架設伺服器，安裝後就能立即使用，非常適合開發初期或小型應用。

• 效能不差，但不適合高併發、大流量情況
• 無法多人同時操作資料（會產生衝突）

適合情境：

• 開發測試階段
• 單人桌面應用程式
• 學習用專案

常見工具：
SQLite、DuckDB

後端怎麼寫程式操作資料庫？

當使用者在前端網站輸入資料（像是註冊表單、商品訂單、留言等），這些資料會透過 HTTP 傳送到後端伺服器。

而後端收到這些資料後，就必須負責「儲存進資料庫」或「從資料庫撈資料出來」來提供前端使用。

🧩 資料怎麼進出資料庫？靠後端程式操作！

這裡的「操作資料庫」，指的是後端透過程式「控制」資料庫執行各種任務，例如：

• 新增一筆留言資料
• 查詢某個會員的訂單
• 修改某筆資料的狀態
• 刪除某筆已取消的訂單

這些操作主要有兩種方式：SQL 指令操作與ORM（物件關聯對應）操作。

用 SQL 語言操作資料庫：後端與資料庫的共通語言

SQL（Structured Query Language）是操作關聯式資料庫的標準語言。

你可以把它想像成後端和資料庫之間的「共通語言」，就像你對資料庫下命令：「我需要這些資料」、「請幫我新增一筆資料」，SQL 就是下命令的方式。

🔤 常見的 SQL CRUD 操作語法

SQL 指令非常靈活，幾乎能完成所有你能想像的資料操作，還能：

• 排序（ORDER BY）
• 分頁（LIMIT, OFFSET）
• 資料表關聯（JOIN）
• 統計（COUNT, SUM, AVG）

🛠️ 後端程式語言怎麼執行 SQL？

實際開發時，我們不會打開一個資料庫介面來手動輸入 SQL，而是會用後端語言（如 Python、JavaScript、Java 等）去「寫程式發送 SQL 指令」來控制資料庫。

每種語言都需要資料庫套件

這些程式語言會透過「資料庫套件」（library / driver）來幫你：

• 建立資料庫連線
• 執行 SQL 指令
• 取得查詢結果
• 處理錯誤與異常

💻 Python 操作資料庫的實例

import sqlite3

conn = sqlite3.connect("users.db")       # 連接資料庫
cursor = conn.cursor()                   # 建立操作指標

cursor.execute("SELECT * FROM users")    # 執行 SQL 查詢
result = cursor.fetchall()               # 取得所有資料列

for row in result:
    print(row)

conn.close()                             # 關閉資料庫連線

import sqlite3

conn = sqlite3.connect("users.db")       # 連接資料庫
cursor = conn.cursor()                   # 建立操作指標

cursor.execute("SELECT * FROM users")    # 執行 SQL 查詢
result = cursor.fetchall()               # 取得所有資料列

for row in result:
    print(row)

conn.close()                             # 關閉資料庫連線

你可以看到：後端程式實際上就是建立一條「對資料庫下指令的通道」，把 SQL 命令發送過去，再接收回傳的資料。

ORM（Object-Relational Mapping）：更貼近程式設計的操作方式

除了直接寫 SQL，還有另一種更高階、更程式化的操作方式：ORM（Object-Relational Mapping），中文叫「物件關聯對應」。

🧠 ORM 是什麼？

ORM 的概念是：

把資料庫的資料表，對應成程式裡的「物件」 你用操作物件的方式來新增、修改、刪除資料，ORM 幫你轉成 SQL 指令

💡 舉例：用 ORM 查詢資料（Django）

# SQL 寫法：
SELECT * FROM users WHERE age > 25;

# Django ORM 寫法：
User.objects.filter(age__gt=25)

# SQL 寫法：
SELECT * FROM users WHERE age > 25;

# Django ORM 寫法：
User.objects.filter(age__gt=25)

你只要寫程式語法，ORM 自動轉譯成 SQL，讓你不需要碰原始 SQL，也能操作資料。

✅ ORM 的優點

• 簡化語法：不用寫 SQL，對程式初學者更友善
• 增加安全性：避免 SQL Injection 等資安問題
• 自動處理資料轉換：字串轉數字、欄位驗證等自動處理
• 易於維護：資料表結構可以用程式碼定義與版本控制

❗ ORM 的限制與缺點

• 效率較低：執行複雜查詢時，比原生 SQL 慢
• 學習成本：需要學 ORM 特有的語法與邏輯（如 model 定義、query chain）
• 不透明：有時不確定 ORM 背後到底轉成了什麼 SQL

📌 也因此，大部分專案會 搭配使用：

• ORM 處理 80% 常見操作（新增、刪除、簡單查詢）
• 原生 SQL 處理進階查詢（報表、統計、效能優化）

🛠 常見 ORM 工具一覽表

📌 不管用 SQL 或 ORM，後端的核心任務都是：

📤 把前端送來的資料「正確、安全」地存進資料庫
📥 從資料庫撈出資料後「清楚、有結構」地回傳給前端

這就是資料流從「使用者 → 前端 → 後端 → 資料庫」再回來的完整旅程。

flowchart LR
    subgraph Application[應用程式層]
        Dev[開發者]
    end
    
    subgraph SQLApproach["SQL 直接查詢方式"]
        SQLCode["SQL 查詢語句<br />SELECT * FROM users<br />WHERE age > 18"]
        SQLRes["原始查詢結果<br />(二維表格資料)"]
    end
    
    subgraph ORMApproach["ORM 物件關聯映射方式"]
        ORMModel["物件模型定義<br />class User:<br />  id, name, age..."]
        ORMQuery["物件導向查詢<br />User.filter(age > 18)"]
        ORMObjects["物件實例集合<br />[User1, User2, ...]"]
    end
    
    subgraph Database["資料庫層"]
        DBTable["資料表<br />users(id, name, age...)"]
    end
    
    Dev -->|1.寫| SQLCode
    Dev -->|1.定義| ORMModel
    Dev -->|2.使用| ORMQuery
    
    SQLCode -->|2.直接執行| DBTable
    DBTable -->|3.返回原始資料| SQLRes
    SQLRes -->|4.需手動轉換為物件| Dev
    
    ORMModel -->|1.5 映射| DBTable
    ORMQuery -->|3.自動轉換為SQL| DBTable
    DBTable -->|4.自動轉換為物件| ORMObjects
    ORMObjects -->|5.直接使用物件方法與屬性| Dev

    classDef application fill:#d4f1f9,stroke:#05acda
    classDef sqlApproach fill:#ffe6cc,stroke:#d79b00
    classDef ormApproach fill:#d5e8d4,stroke:#82b366
    classDef database fill:#f8cecc,stroke:#b85450
    
    class Application application
    class SQLCode,SQLRes sqlApproach
    class ORMModel,ORMQuery,ORMObjects ormApproach
    class Database,DBTable database

資料存在哪裡不重要，怎麼拿回來才是重點

對使用者來說，他們只在乎一件事：

「我想看的資料，能不能正確快速地出現在畫面上？」

不管你把資料存在哪裡 —— 是放在 MySQL、MongoDB、Google Sheet，甚至是 Excel 檔案 —— 使用者都不會在乎，前端工程師也不需要知道資料的實際來源。

📌 重點是兩個：

1. 我要的資料能不能準確地取得？
2. 拿到的資料格式，能不能馬上使用在網頁上？

這就好像：

• 去便利商店，你只管結帳拿到商品，不會在乎它是從哪個物流中心送來的。
• 用外送 App 點餐，你只關心食物有沒有送到家，而不是它是從哪間廚房、哪個備料倉出貨的。

那麼，前端是怎麼跟後端「要資料」的？後端又是怎麼把資料送過來的？

這時候，一個非常重要的橋樑出現了 —— 叫做 API。

後端開 API 給前端使用的概念

API 是 Application Programming Interface 的縮寫，中文叫「應用程式介面」。

說得簡單一點，API 就像是：

一台「點餐機」，讓前端可以按按鈕，點自己想要的資料，後端就根據指令去廚房（資料庫）準備好餐點（資料），然後送回來。

更技術一點的說法是：

API 是前端與後端之間的「資料交換通道」，前端透過這條通道發送請求，後端再透過這條通道回傳資料。

例如你在一個會員系統中想要取得所有使用者的清單：

• 前端會發送一個「請把所有使用者資料給我」的請求（Request）
• 後端就會把資料庫裡的使用者列表查詢出來，然後回傳（Response）給前端

這整個流程，就是靠 API 完成的。

一個 API 長什麼樣子？

在網頁中，一個 API 通常會是一個特定的網址，像這樣：

https://example.com/api/users

https://example.com/api/users

你可以透過這個網址「請求資料」，根據使用的請求方法（如 GET），就能取得你需要的資訊。

💡 常見的 API 請求範例

Request / Response 與 API 文件

Request：前端發送請求

當前端需要某些資料時，會發出一個 HTTP Request，也就是一個請求。這個請求包含幾個重要的資訊：

🧾 舉例：一個新增留言的 POST 請求

POST /api/comments
Content-Type: application/json

{
  "userId": 3,
  "content": "這篇文章很棒！"
}

POST /api/comments
Content-Type: application/json

{
  "userId": 3,
  "content": "這篇文章很棒！"
}

Response：後端回傳資料

後端收到請求後，會處理對應的動作（查資料、寫入資料、驗證等），然後透過 API 回傳一段資料（Response）給前端。

這段資料通常是用 JSON 格式 表示，例如：

{
  "id": 1,
  "name": "小明",
  "email": "ming@example.com"
}

{
  "id": 1,
  "name": "小明",
  "email": "ming@example.com"
}

JSON（JavaScript Object Notation）是一種輕量級的資料格式，適合用來表示結構化資料，也很容易被 JavaScript 或其他語言讀取。

📌 這段資料回來後，前端就可以用它來更新畫面，例如顯示使用者清單、商品明細、留言內容等等。

API 文件是什麼？為什麼重要？

當前端工程師要透過 API 取得資料時，他們需要知道：

• 要打哪個網址？
• 是 GET 還是 POST？
• 要傳哪些欄位？
• 回來的資料長什麼樣子？

這時候就需要一份清楚的「API 文件」，就像說明書一樣，告訴你怎麼使用 API，不會用錯方式或漏掉資料。

常見的 API 文件工具有：

• Swagger / OpenAPI：可視化、互動式說明與測試
• Postman：可建立範例請求，測試與記錄 API 行為
• Redoc / Stoplight：API 文件管理與自動產生工具

🧩 前後端合作的關鍵橋樑

沒有 API，前端就像沒有菜單的餐廳，不知道要怎麼點餐
沒有 API 文件，前端就像盲目點餐，可能點了後廚不會做的菜

良好的 API 設計與清楚的 API 文件，是前後端合作順利的關鍵。

資料不管存在哪裡（MySQL、MongoDB、雲端 Firebase），最終都會透過後端開放的 API 提供給前端使用。

整體流程可以簡化成：

sequenceDiagram
    participant Frontend as 前端
    participant Backend as 後端
    participant DB as 資料庫
    
    Frontend->>Backend: 1. 發送 API Request (按鈕點擊)
    Backend->>DB: 2. 查詢資料
    DB->>Backend: 3. 返回查詢結果
    Backend->>Frontend: 4. 回傳 API Response
    Frontend->>Frontend: 5. 更新畫面

學會看懂、使用、設計 API，是前後端溝通、系統架構設計、甚至資料串接整合的必備技能！

延伸閱讀：REST vs GraphQL 是什麼？

當我們說「API」時，大多指的是後端設計出來的資料通道，那這些通道要怎麼設計呢？

其實也有不同風格，最常見的兩種設計方式就是：

• RESTful API（目前最廣泛使用的方式）
• GraphQL（一種更彈性的新興 API 設計方式）

這兩種方式的目標都是一樣的：提供資料給前端使用，但在結構設計、資料取得方式、靈活性上卻有明顯差異。

RESTful API：簡單清楚的「資源導向」設計

REST（Representational State Transfer）是一種 API 設計風格，最核心的理念是：

「每一種資源（資料）都有自己的網址（URL），你用不同的 HTTP 方法（GET、POST、PUT、DELETE）去操作它。」

🔍 舉例：商品系統的 REST API

每一個「資料操作」都對應到一個 URL + HTTP 方法的組合，這種方式很直觀、規則清晰，也容易理解與除錯。

✅ REST 的優點：

• 結構簡單，容易入門
• 有明確標準（HTTP 方法 + 路由）
• 各種程式語言與工具支援度高
• API 文件好產生，容易測試

❗ REST 的限制：

• 有時會傳回過多資料，但你只需要其中幾個欄位
• 想拿多個資料來源（像：使用者 + 他的訂單 + 訂單商品）時，要多次請求
• 資料格式是後端決定，前端彈性小

GraphQL：前端決定「要什麼資料」的 API 設計方式

GraphQL 是由 Facebook 推出的 API 技術，主打由前端來決定資料的內容與結構，不像 REST 那樣「一個 URL 對應一種資料」。

🔍 舉例：GraphQL 查詢語法

假設你要查詢某位使用者的名字與信箱，只需要寫這樣的查詢：

query {
  user(id: 1) {
    name
    email
  }
}

query {
  user(id: 1) {
    name
    email
  }
}

只會回傳你要的 name 和 email，而不會多傳其他像 phone、address 的資料。這種「精準要資料」的方式，在 REST 裡做不到。

📦 GraphQL 的運作方式是：

• 所有資料都從 一個統一的入口 /graphql 存取
• 前端自己撰寫「查詢語法」（Query）或「修改語法」（Mutation）
• 後端只回傳前端指定的欄位資料

✅ GraphQL 的優點：

• 資料請求更精準：不會拿到多餘欄位，節省流量與處理時間
• 一次拿多種資料：不用多次請求，前端可以把需要的資料都寫進一個查詢
• 前端自主性更高：可以自己決定要拿什麼欄位，靈活快速

❗ GraphQL 的限制與挑戰：

• 學習曲線較高：需要學新的語法與查詢方式
• 後端實作更複雜：需要定義 schema 與 resolver 邏輯
• 除錯與快取機制較難：不像 REST 可搭配 HTTP 快取與瀏覽器工具直接測試
• 權限控制要更細緻：因為前端可以請求任意欄位，要確保使用者不能「超取」敏感資料

REST vs GraphQL 差異整理表

結語：你已經踏出資料流的第一步！

恭喜你！現在你已經大致理解：

• 資料是如何存進資料庫的
• 後端怎麼寫程式讀取資料
• API 是怎麼把資料提供給前端使用的

這是前後端合作的基礎知識，也是在學習 Web 開發中非常重要的一環。未來如果你要當前端工程師、後端工程師，或是全端開發者，這些概念都會一路陪伴你。