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

更新日期： 2025 年 4 月 3 日

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

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

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

為什麼需要資料庫？

當初學者第一次接觸網頁開發，常常會有這樣的疑問：

我把表單填完了，資料不是已經出現在網頁上了嗎？那還需要什麼資料庫？不能就這樣存著嗎？

這是一個很合理也很重要的問題。

要理解答案，我們可以先來想一想，如果不使用資料庫，只把資料存在前端（瀏覽器）或使用者自己的電腦上，會發生什麼問題？

為什麼資料不能只存在前端？

❌ 資料不會永久保存

前端（如 HTML、JavaScript）只是用來「呈現畫面」，它沒有能力自己儲存資料。

即使透過瀏覽器的 LocalStorage、SessionStorage 或 Cookie 儲存資料，這些資料也有以下問題：

• 容易被清除（例如清除瀏覽紀錄）
• 只能儲存在使用者自己的電腦上，別人看不到
• 無法跨裝置同步，你用電腦登入和用手機登入是兩個不同的世界

如果今天你登入一個網站，明天換一台電腦或換手機再登入時，資料卻全都不見了，這樣的系統就沒什麼實用性。

❌ 每個使用者各自為政，資料無法整合

想像你做了一個留言板應用，每位使用者的留言都只存在自己的電腦裡。這會導致什麼問題？

• 小明留言只有小明看得到
• 小美進來什麼也看不到，以為沒有人使用
• 系統無法呈現「全部留言」的統一清單
• 更別說管理、檢舉、刪除留言了

📌 只有將資料統一儲存在一個中心（資料庫），所有人才能共用、互動、整合資料。

❌ 資料安全性非常低

若將帳號、密碼、信用卡資訊等敏感資料存在前端，不僅容易被竄改，也可能被他人「偷看」。

• 前端程式碼對使用者來說是完全透明的
• 有經驗的使用者可以開啟瀏覽器開發者工具，看到你儲存的所有內容
• 資料未經加密就儲存在 LocalStorage，形同明文上鎖，形同沒鎖

📌 資料應該存在受控、受限權限的伺服器端資料庫中，這樣才能透過驗證、權限管理來保護資料安全。

❌ 無法做統一管理與查詢

前端只能顯示畫面，沒有強大的資料查詢與管理能力。想做以下這些功能嗎？你會發現前端幾乎做不到：

• 搜尋某位使用者的所有訂單
• 統計哪個商品最熱賣
• 找出近一週內註冊的新用戶
• 刪除某筆不當留言

📌 這些都需要結構化資料 + 強大的查詢語言（像是 SQL），也就是我們接下來要講的——資料庫的工作。

資料要怎麼儲存才有組織？

在還沒學習資料庫之前，我們可能會很直覺地把資料當作「一串文字」來儲存。

例如你想記下某個人的基本資料，可能會寫成這樣：

28 歲的小明住在台北

看起來沒什麼問題，清楚明瞭。那如果你還想記住其他人呢？你可能會開始這樣記在記事本（Notepad）裡：

28 歲的小明住在台北
26 歲的小美住在高雄
30 歲的小張住在新竹

這樣當作備忘錄沒問題，但如果你要開發一個網站，讓程式能夠讀取、搜尋、管理這些資料，你會很快遇到困難。

純文字的問題在哪裡？

當你開始思考要用程式處理這些資料時，問題馬上浮現：

❓你想找出所有「住在台北」的人？

很抱歉，這些資料只是自然語言，程式看不懂誰是「居住地」欄位，也不知道「台北」是屬於哪個人的什麼資訊。

你可能得用關鍵字模糊搜尋、用正規表達式分析，成本高又容易出錯。

❓其中一筆資料的格式不一致呢？

例如你多寫了一筆：

小豪 / 年齡: 25 / 地區：台中

這筆資料的格式就完全跟其他筆不同，程式不會知道 / 是分隔符號，這樣一來整份資料檔就變得難以統一解析。

資料越多、錯誤越多，維護成本也跟著暴增。

❓資料量一大，怎麼搜尋、怎麼分類？

當你有 10 筆資料時，也許還能用肉眼對照。

但如果你有 10,000 筆資料，純文字的方式就完全不敷使用。搜尋速度慢、資料難以篩選、分類更是天方夜譚。

有結構的儲存方式：從 Notepad 到「表格」

我們需要更結構化的方式來儲存資料，於是開始用類似 Excel 表格的形式，明確標出每個欄位的意義。像這樣：

這時候你就可以清楚知道：

• 哪一欄是姓名
• 哪一欄是年齡
• 哪一欄是居住地

每一筆資料都是一列（row），每一個屬性都是一欄（column），這樣程式就可以非常精準地搜尋、篩選、排序這些資料。例如：

• 找出所有「住在台北」的人
• 排序「年齡從大到小」
• 計算「平均年齡」

這正是資料庫最擅長的事情。

表格概念如何應用到網頁開發中？

你可能想問：「那這種表格格式怎麼跟我們開發網頁有關？」

答案是：這就是表單 + 後端程式 + 資料庫共同運作的核心概念！

• 前端表單收集資料（使用者輸入）
• 後端程式接收資料（例如 Python、Node.js）
• 資料庫儲存資料（用表格的方式）

我們在開發網頁或 App 的時候，會用這樣一整套流程來「接收資料 → 儲存資料 → 讀取資料 → 顯示資料」，而不是單靠文字檔或瀏覽器記憶。

為什麼資料儲存要有格式與結構？

你可以把純文字想像成「亂塞在抽屜裡的便條紙」，而資料表格就像是「分類整齊的資料櫃」。
如果你想：

• 搜尋特定條件的資料
• 統計數據
• 更新其中一筆紀錄
• 防止格式錯誤
• 管理大量資料（幾千萬筆）

那你就需要一個有結構、有欄位、有規則的儲存方式，這就是資料表、資料庫登場的地方。

下一節，我們就來看看這些幫我們管理資料的「資料庫」究竟是什麼，有哪些種類，以及它們是怎麼幫助我們開發網站的！

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

資料庫（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()                             # 關閉資料庫連線

你可以看到：後端程式實際上就是建立一條「對資料庫下指令的通道」，把 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)

你只要寫程式語法，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

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

💡 常見的 API 請求範例

Request / Response 與 API 文件

Request：前端發送請求

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

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

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

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

Response：後端回傳資料

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

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

{
  "id": 1,
  "name": "小明",
  "email": "[email protected]"
}

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
  }
}

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

📦 GraphQL 的運作方式是：

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

✅ GraphQL 的優點：

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

❗ GraphQL 的限制與挑戰：

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

REST vs GraphQL 差異整理表

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

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

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

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