客戶端 → 伺服器：GET /api/users/123
伺服器 → 客戶端：{ "id": 123, "name": "Alice" }
（對話結束）
Code language: JavaScript (javascript)

// 客戶端建立 WebSocket 連線
const ws = new WebSocket("ws://example.com/chat");

ws.onopen = () => {            // 連線建立成功時
  ws.send("Hello!");           // 傳訊息給伺服器
};

ws.onmessage = (event) => {    // 收到伺服器訊息時
  console.log(event.data);     // 印出來
};
Code language: JavaScript (javascript)

const ws = new WebSocket("ws://example.com/chat");
// ↑ 跟 example.com 建立一條持續連線（注意是 ws:// 不是 http://）

ws.onopen = () => {
// ↑ 「連線成功時」要做的事

  ws.send("Hello!");
  // ↑ 透過這條連線傳訊息出去

ws.onmessage = (event) => {
// ↑ 「收到訊息時」要做的事（伺服器可以隨時主動推訊息過來！）

  console.log(event.data);
  // ↑ 把收到的訊息印出來
Code language: JavaScript (javascript)

HTTP（一問一答）：
客戶端 → 有新訊息嗎？ → 伺服器：沒有
客戶端 → 有新訊息嗎？ → 伺服器：沒有
客戶端 → 有新訊息嗎？ → 伺服器：有！給你
（每次都要重新問）

WebSocket（持續連線）：
客戶端 ←→ 伺服器（連線建立）
伺服器 → 有新訊息了！直接推給你
伺服器 → 又有一則！直接推給你
（連線一直開著，伺服器主動推送）

一般通訊（經過伺服器）：
Alice → 伺服器 → Bob

WebRTC（點對點）：
Alice ←→ Bob（直接連線，不經過伺服器）

但要先「牽線」：
Alice → 信令伺服器（我想跟 Bob 通話）
Bob ← 信令伺服器（Alice 想跟你通話）
Alice ←→ Bob（好，我們直接連）

發布-訂閱模式：

溫度感測器 → 發布到「kitchen/temperature」主題 → Broker（中間人）
                                                    ↓
手機 App ← 訂閱「kitchen/temperature」主題 ← Broker
儀表板   ← 訂閱「kitchen/temperature」主題 ← Broker

感測器只管發布，不用知道誰在聽
手機和儀表板只管訂閱，不用知道誰在發
Broker 負責轉發

HTTP（每次都完整請求）：
感測器 → POST /api/temperature { "value": 25.3 }
         ↑ 每次要帶完整的 HTTP headers，很重

MQTT（輕量發布）：
感測器 → 發布 "25.3" 到 "kitchen/temp"
         ↑ 封包很小，省電省頻寬
Code language: JavaScript (javascript)

你的應用需要什麼？
│
├─ 一般的 Web API（讀寫資料）
│   → 用 HTTP（REST API）
│
├─ 即時雙向通訊（聊天、通知、即時更新）
│   → 用 WebSocket
│
├─ 視訊/語音通話、螢幕分享（需要低延遲 P2P）
│   → 用 WebRTC
│
└─ IoT 設備、感測器（低功耗、低頻寬）
    → 用 MQTT

壞的 API（看不出在幹嘛）：
GET  /getUser?id=123
POST /createNewUser
POST /deleteUser
GET  /fetchAllUsersList

好的 API（一看就懂）：
GET    /v1/users/123       ← 取得使用者 123
POST   /v1/users           ← 新增使用者
DELETE /v1/users/123       ← 刪除使用者 123
GET    /v1/users           ← 取得使用者列表

壞：GET /getUsers          ← 動詞 + 名詞，冗餘
好：GET /users             ← HTTP 動詞已經表示動作了

/v1/users     ← 第一版 API
/v2/users     ← 第二版，可能改了回傳格式

壞：GET /users             ← 一次回傳全部 10 萬筆？伺服器炸了
好：GET /users?page=1&limit=20  ← 每次只回 20 筆，第 1 頁

壞：永遠回 200，把錯誤藏在 body 裡
{
  "status": 200,
  "error": "User not found"   ← 明明找不到，還回 200？
}

好：用正確的 HTTP 狀態碼
404 Not Found
{
  "error": "User not found",
  "code": "USER_NOT_FOUND"
}
Code language: JavaScript (javascript)

當你呼叫 API 太頻繁：

HTTP/1.1 429 Too Many Requests
{
  "error": "Rate limit exceeded",
  "retry_after": 60        ← 60 秒後再試
}
Code language: JavaScript (javascript)

X-RateLimit-Limit: 100        ← 每小時最多 100 次
X-RateLimit-Remaining: 23     ← 還剩 23 次
X-RateLimit-Reset: 1672531200 ← 額度重置的時間（Unix timestamp）
Code language: HTTP (http)

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email format is invalid",
    "details": [
      {
        "field": "email",
        "issue": "Must be a valid email address"
      }
    ]
  }
}
Code language: JSON / JSON with Comments (json)

需求：瀏覽商品、下單、查訂單
分析：
  - 一般的讀寫操作 → HTTP REST API
  - 訂單狀態更新通知 → 可以用 HTTP 輪詢，或升級用 WebSocket

選擇：以 HTTP 為主，通知部分視規模決定

需求：一對一聊天、群組聊天、已讀通知
分析：
  - 訊息要即時送達 → 需要持續連線
  - 伺服器要能主動推訊息 → HTTP 做不到

選擇：WebSocket（訊息傳遞）+ HTTP（使用者管理、歷史訊息查詢）

需求：多人視訊通話、螢幕分享
分析：
  - 影音串流需要極低延遲 → WebSocket 延遲還是太高
  - 最好不經過伺服器 → 點對點直連

選擇：WebRTC（影音串流）+ WebSocket（信令 + 聊天）+ HTTP（使用者管理）

需求：1000 個感測器回報溫度、濕度
分析：
  - 設備功耗低 → 需要輕量級協定
  - 資料是「發布」性質 → 不需要一問一答
  - 多個面板需要訂閱同一批資料

選擇：MQTT（感測器資料收集）+ HTTP（管理介面）+ WebSocket（即時儀表板）

必看懂（會一直出現）：
- HTTP 方法（GET、POST、PUT、DELETE）
- 狀態碼的分類（2xx、4xx、5xx）
- WebSocket 的 ws:// 連線和事件處理
- REST API 的 URL 命名規則
- 分頁和限流的基本概念

知道就好（遇到再查）：
- gRPC：Google 的高效能 RPC 框架，用 Protocol Buffers 序列化
- GraphQL：Facebook 的查詢語言，客戶端指定要哪些欄位
- Server-Sent Events (SSE)：伺服器單向推送，比 WebSocket 簡單
- HTTP/2 Server Push：伺服器主動推送資源
- AMQP：進階訊息佇列協定，比 MQTT 更複雜但功能更完整
Code language: JavaScript (javascript)