---
# System prepended metadata

title: 第二堂：API 是什麼？介接外部服務自己來
tags: [2026 後端工程師體驗營]

---

# 第二堂：API 是什麼？介接外部服務自己來


* 記得錄影
* **下週一 21:00 釋出最終任務，將會有實際改 Code 與測試環節**
* 即日起提供，[一對一諮詢連結](https://liberating-turtle-5a2.notion.site/2e16a246851880a28857c25c4df931b2)，提供**課程介紹**與**學習方向**討論
* 獲得書籍同學，週五前填表者，將準時於週六日發送~
* [簡報模式](https://hexschool.github.io/backend-camp-game/dev)

## 課程結束後
* 21:30 準時提供實體活動報名連結
* 每日任務抽書活動



## 第一部分：當你輸入網址按下 Enter，背後發生了什麼事？

* 簡報：Day 5｜拖曳排序：HTTP 請求流程

### 你每天都在發網路請求！

```
1. 瀏覽器發送「請求」(Request)
2. 請求透過網路傳送到伺服器
3. 伺服器處理請求
4. 伺服器回傳「回應」(Response)
5. 瀏覽器顯示結果
```

**這個「一來一往」的過程，就叫做網路請求！**

你每天上網都在發網路請求：
- 打開 Google 搜尋
- 看 YouTube 影片
- 滑 Instagram
- 逛蝦皮購物

**通通都是網路請求！**

### 互動問題

> 請問大家：你今天打開過幾個網站？每打開一個網站，就是發了一次網路請求喔！

---

## 第二部分：API 基礎觀念 - 用別人的服務都靠他

### 一般網址 vs API


### API 的全名

**API = Application Programming Interface（應用程式介面）**

簡單說：API 是程式與程式之間溝通的橋樑。

### JSON 資料格式
JSON 是程式之間交換資料的標準格式：

```json
{
  "name": "王小明",
  "age": 25,
  "skills": ["JavaScript", "Python", "Node.js"],
  "isStudent": false
}
```


### 實際的 API 回應長這樣

```json
{
  "success": true,
  "data": {
    "coaches": [
      {
        "id": 1,
        "name": "海克絲",
        "role": "教練",
        "skills": ["重訓", "有氧", "瑜珈"]
      },
      {
        "id": 2,
        "name": "李燕容",
        "role": "教練",
        "skills": ["皮拉提斯", "伸展"]
      }
    ]
  }
}
```

---

## 第三部分：資料流解析

### LiveFit 有多少個 API？

LiveFit 健身平台總共有 **29 個 API**！

* [>>API文件<<](https://www.notion.so/38e4dd6775894e94a8f575f20ca5b867?pvs=21)
* 以「教練新增一門課程為例」：Day 4｜後端角色說明
* 顧客想觀看教練列表課：Day 5｜API 實際操作示範

| 模組 | API 數量 | 功能範例 |
|------|----------|----------|
| 使用者 (users) | 7 個 | 註冊、登入、個人資料、修改密碼 |
| 教練 (coaches) | 3 個 | 教練列表、教練詳情、教練課程 |
| 課程 (courses) | 3 個 | 課程列表、預約課程、取消預約 |
| 堂數方案 (credit-package) | 4 個 | 方案列表、購買堂數 |
| 技能 (skill) | 3 個 | 技能列表、新增/刪除技能 |
| 教練後台 (admin) | 8 個 | 開課、收益統計、課程管理 |
| 上傳 (upload) | 1 個 | 圖片上傳 |

**這就是後端工程師要做的事：設計並實作這些 API！**

### 完整的資料流

教練資料怎麼從資料庫跑到網頁上？

```
前端發請求 → 後端處理 → 資料庫查詢 → 後端回傳 → 前端顯示
```

**步驟拆解：**

1. **前端**：使用者看到的網頁，發送 API 請求
2. **後端**：接收請求，處理邏輯，連接資料庫
3. **資料庫**：儲存資料，回傳查詢結果
4. **後端**：把資料包成 JSON 回傳
5. **前端**：收到 JSON，顯示在畫面上


---

## 第四部分：第三方服務串接

### 後端工程師 = 中央調度站
* 簡報：Day 5｜第三方 API 服務


後端工程師的工作不只是連接自己的資料庫，更多是「整合各種第三方服務」！

| 服務類型 | 範例 |
|---------|------|
| 金流服務 | 綠界、藍新、LINE Pay |
| 第三方登入 | Google、Facebook、Apple |
| 簡訊/郵件通知 | Twilio、SendGrid |
| 雲端儲存 | AWS S3、Google Cloud |
| 地圖服務 | Google Maps API |

**這些服務都有提供 API，後端工程師負責把它們「串」起來！**

### 實際案例：購買課程

當使用者在網站點擊「購買」：

```
1. 點擊購買 → 前端送請求給後端
2. 後端呼叫金流 API → 建立訂單
3. 金流處理付款 → 通知後端成功
4. 更新資料庫 → 訂單狀態「已付款」
5. 購買成功！ → 前端顯示結果
```


## 第五部分：API 權限驗證與 JWT
* 簡報：Day 4｜後端角色說明
* 簡報：Day 8 
### API 需要權限驗證

並非所有 API 都能隨意存取，涉及個人資料的操作都需要驗證身份：

| API 類型 | 是否需要驗證 | 範例 |
|---------|-------------|------|
| 公開 API | 不需要 | 取得教練列表、課程列表 |
| 私人 API | 需要 | 查看個人資料、購買課程、修改密碼 |

### HTTP 無狀態特性

HTTP 協定本身是「無狀態」的，伺服器不會記住每個請求來自誰。

**解決方案：JWT（JSON Web Token）**

登入成功後，伺服器發給使用者一張「通行證」，之後每次請求都帶著它。

### JWT 運作原理（餐廳號碼牌比喻）

> 


### 為什麼無法偽造

- 簽名由後端的「秘密金鑰」產生
- 只有後端知道這個金鑰
- 竄改內容會導致簽名驗證失敗

### 秘密金鑰的存放位置

| 做法 | 說明 |
|-----|------|
| ❌ 寫在程式碼 | 上傳 GitHub 後全世界都能看到 |
| ✅ 放在 `.env` 檔案 | 用 `.gitignore` 防止上傳 |

```
# .env 檔案範例
JWT_SECRET=hexschool666
JWT_EXPIRES_DAY=30d
```

### 前端儲存位置：LocalStorage vs Cookie

| 特性 | LocalStorage | Cookie |
|------|--------------|--------|
| 容量 | 約 5MB | 約 4KB |
| 自動帶上請求 | 否，需手動加入 Header | 是，自動送給伺服器 |
| 過期時間 | 永久（除非手動刪除） | 可設定 |

### 使用 Chrome DevTools 查看

1. 按 `F12` 開啟開發者工具
2. 點選 `Application` 面板
3. 左側展開 `Storage → Local Storage`
4. 點擊網域名稱查看儲存的資料

### 安全注意事項

- JWT 被竊取等於身份被冒用
- 離開電腦前記得鎖定螢幕
  - Mac：`Cmd + Ctrl + Q`
  - Windows：`Win + L`

