直接存取資料庫（危險！不會這樣做）：
App → 直接連 Database → SELECT * FROM orders WHERE user_id = 123

透過 API（正確做法）：
App → 發 HTTP 請求給 API → API 驗證身份 → API 查資料庫 → 回傳結果

Client 發出請求（Request）：
GET /api/orders/456

Server 回傳回應（Response）：
{
  "id": 456,
  "status": "shipped",
  "total": 1200
}
Code language: JavaScript (javascript)

# 建立一個新使用者
curl -X POST https://api.example.com/users \   # 對 /users 發出 POST 請求（建立）
     -H "Content-Type: application/json" \      # 告訴 server：我送的是 JSON 格式
     -H "Authorization: Bearer eyJhb..." \      # 附上身份驗證 token
     -d '{"name": "Alice", "email": "[email protected]"}' # 要建立的資料
Code language: PHP (php)

{
  "id": 789,
  "name": "Alice",
  "email": "[email protected]",
  "created_at": "2026-02-23T10:00:00Z"
}
Code language: JSON / JSON with Comments (json)

資源（名詞）  +  動作（動詞）  =  API 端點

/users         GET            → 取得所有使用者
/users/123     GET            → 取得特定使用者
/users         POST           → 建立新使用者
/users/123     PUT            → 更新特定使用者
/users/123     DELETE         → 刪除特定使用者

有狀態（Stateful）的對話：
你：「我要查訂單」
店員：（記住你是誰）「好的，王先生，你的訂單...」

無狀態（Stateless）的對話：
你：「我是王先生，這是我的會員卡，我要查訂單 456」
店員：「好的，456 號訂單已出貨」
你：「我是王先生，這是我的會員卡，我要查訂單 789」
店員：「好的，789 號訂單處理中」

用 REST，你可能需要兩個請求：

1. GET /users/123
   回傳：{ id, name, email, phone, address, birthday, ... }
   → Over-fetching：你只需要 name，卻拿到一堆不需要的欄位

2. GET /users/123/orders
   回傳：[{ id, status, total, items, ... }, ...]
   → 要發第二個請求才能拿到訂單
   → Under-fetching：一個請求拿不到你要的所有資料

# 用 GraphQL，一個請求搞定，而且只拿你要的欄位：

query {
  user(id: 123) {    # 我要 ID 123 的使用者
    name             # 只要名字
    orders {         # 還有他的訂單
      id             # 訂單只要 id
      status         # 和狀態
    }
  }
}
Code language: PHP (php)

{
  "data": {
    "user": {
      "name": "Alice",
      "orders": [
        { "id": 456, "status": "shipped" },
        { "id": 789, "status": "pending" }
      ]
    }
  }
}
Code language: JSON / JSON with Comments (json)

Q1: 你的前端需要的資料格式是否經常變動？
├─ 經常變（快速迭代中）→ 考慮 GraphQL
└─ 很穩定 → 繼續 Q2

Q2: 前端需要的資料是否需要多次 API 呼叫才能湊齊？
├─ 是（要打好幾個 endpoint）→ 考慮 GraphQL
└─ 一個 endpoint 就能搞定 → 繼續 Q3

Q3: 你的團隊有 GraphQL 經驗嗎？
├─ 有 → 用 GraphQL
└─ 沒有 → 用 REST（學習成本低，生態成熟）

用檔案存資料：
- 想找一筆訂單？ → 讀取整個檔案，一行行找
- 兩個人同時改資料？ → 檔案可能被覆蓋
- 想保證「扣款和出貨」一起完成？ → 自己寫邏輯，超容易出 bug

用資料庫：
- 想找一筆訂單？ → 用索引（Index），毫秒級找到
- 兩個人同時改資料？ → 資料庫自動處理並發（Concurrency Control）
- 想保證「扣款和出貨」一起完成？ → 交易（Transaction），全成功或全失敗

-- 資料長什麼樣（Schema），必須事先定義
CREATE TABLE users (
    id    INT PRIMARY KEY,    -- 每個使用者有唯一 ID
    name  VARCHAR(100),       -- 名字，最多 100 字
    email VARCHAR(200)        -- 信箱，最多 200 字
);

-- 查詢：找出所有訂單金額超過 1000 的使用者
SELECT users.name, orders.total
FROM users
JOIN orders ON users.id = orders.user_id   -- 把兩張表連起來
WHERE orders.total > 1000;                 -- 條件：金額超過 1000

// 直接塞資料，不用事先定義 Schema
db.users.insertOne({
    name: "Alice",
    email: "[email protected]",
    orders: [                      // 訂單直接塞在使用者裡面
        { id: 1, total: 1500 },
        { id: 2, total: 800 }
    ]
})

// 查詢：找出有訂單金額超過 1000 的使用者
db.users.find({ "orders.total": { $gt: 1000 } })
Code language: PHP (php)

ACID 就是資料庫的四個保證：

A - Atomicity（原子性）
    「全做或全不做」
    例：轉帳時，扣款和入帳要麼都成功，要麼都不做

C - Consistency（一致性）
    「資料永遠合理」
    例：帳戶餘額不會變成負數

I - Isolation（隔離性）
    「互不干擾」
    例：兩個人同時轉帳，結果和一個一個轉一樣

D - Durability（持久性）
    「存了就不會丟」
    例：系統當機重啟後，資料還在

Q1: 你的資料之間有明確的關聯嗎？（例如：使用者有訂單，訂單有商品）
├─ 有，而且經常需要跨表查詢 → SQL
└─ 沒有太多關聯，或可以反正規化 → 繼續 Q2

Q2: 資料格式會經常改變嗎？
├─ 會（快速迭代、每個物件欄位不同）→ NoSQL
└─ 不太會 → 繼續 Q3

Q3: 你需要強一致性（ACID）嗎？
├─ 需要（金融、庫存等不能出錯的）→ SQL
└─ 可以接受短暫的不一致（社群貼文、日誌等）→ NoSQL

Q4: 你預期要處理多大量的資料？
├─ 超大量 + 需要水平擴展 → NoSQL
└─ 中等規模 → SQL（PostgreSQL 已經很能打了）

1. 使用者在手機 App 按下「查看訂單」

2. App（Client）發出 REST API 請求：
   GET /api/orders?user_id=123
   Authorization: Bearer eyJhb...

3. Server 收到請求，API 層處理：
   - 驗證 token（這人是誰？有權限嗎？）
   - 解析參數（要查 user_id=123 的訂單）

4. Server 查詢資料庫：
   SELECT * FROM orders WHERE user_id = 123;

5. 資料庫回傳結果，Server 組裝回應：
   { "orders": [{ "id": 456, "status": "shipped" }] }

6. App 收到回應，顯示在畫面上
Code language: JavaScript (javascript)